ASEP: a secure and flexible commit protocol for mls distributed ...

880

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

ASEP: A Secure and Flexible Commit Protocol for MLS Distributed Database Systems Indrajit Ray, Luigi V. Mancini, Sushil Jajodia, Senior Member, IEEE, and Elisa Bertino, Member, IEEE AbstractÐThe classical Early Prepare commit protocol (EP), used in many commercial systems, is not suitable for use in multilevel secure distributed databases systems that employ a locking protocol for concurrency control. This is because EP requires that read locks are not released by a participant during its window of uncertainty; however, it is not possible for a locking protocol to provide this guarantee in a multilevel secure system (since the read lock of a higher-level transaction on a lower-level data object must be released whenever a lower-level transaction wants to write the same data). The only available work in the literature, namely the Secure Early Prepare protocol (SEP), overcomes this difficulty by aborting those distributed transactions that release their low-level read locks prematurely. We see this approach as being too restrictive. One of the major benefits of distributed processing is its robustness to failures, and SEP fails to take advantage of this. In this work, we propose the Advanced Secure Early Prepare commit protocol (ASEP) to solve the above problem together with a number of language primitives that can be used as system calls in distributed transactions. These primitives permit features like partial rollback and forward recovery to be incorporated within the transaction model, and allow a distributed transaction to proceed even when a participant has released its low-level read locks prematurely. This not only offers flexibility, but can also be used, if desired, by a sophisticated programmer to trade off consistency for atomicity of the distributed transaction. Index TermsÐDatabase management systems, distributed databases, security, multilevel security, transaction processing, commit protocol.

æ 1

I

INTRODUCTION

a distributed database, there are several logical objects that are physically located at different sites or nodes. A user can initiate a distributed transaction at any site. If access to objects stored at remote sites is required, the distributed transaction initiates a subtransaction at the remote site. To guarantee correct execution of distributed transactions, each site in the distributed database is equipped with a concurrency control protocol and an atomic commit protocol. The concurrency control protocol ensures that the execution of all local transactions and subtransactions at each site is serializable. The commit protocol, on the other hand, ensures the atomicity of a distributed transaction: All its subtransactions should either commit or abort. There are several different concurrency N

. I. Ray is with the Department of Computer and Information Sciences, University of Michigan-Dearborn, Dearborn, MI 48128. E-mail: [email protected]. . L.V. Mancini is with the Dipartimento di Scienze dell'Informazione, Universita La Sapienza di Roma, Rome, Italy. E-mail: [email protected]. . S. Jajodia is with the Center for Secure Information Systems and Department of Information and Software Systems Engineering, George Mason University, Fairfax, VA 22030-4444. E-mail: [email protected]. . E. Bertino is with the Dipartimento di Scienze dell'Informazione, Universita di Milano, Via Comelico 39 20135 Milano, Italy. E-mail: [email protected]. Manuscript received 25 Nov. 1996; revised 25 Aug. 1997; accepted 19 June 1998. For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference IEEECS Log Number 104383.

and commit protocols with two-phase locking (2PL) and basic two-phase commit (2PC) being the most well-known concurrency and commit protocols, respectively [2]. A major problem of the locking protocols in multilevel secure (MLS) systems is that in order to avoid a covert channel, any read lock acquired by a high-level transaction on a low-level data object must be released whenever a low transaction attempts to acquire a write lock on the same data object. Unfortunately, this has grave implications for the corresponding commit protocol, especially for the early prepare commit protocol (EP) [13], [15]. What it implies is that read locks may get released within a subtransaction's window of uncertainty (period after a participant has voted yes to commit its subtransaction, but before it receives the commit or abort decision from the coordinator), possibly resulting in nonserializable executions [9], [10]. To guarantee serializability, Atluri et al. proposed a secure early prepare commit protocol (SEP) in [1]. SEP introduces a confirmation phase before the decision phase of EP to ensure that if a read lock is released prematurely within the window of uncertainty, the subtransaction and, therefore, the distributed transaction are aborted. We feel that such a strategy of aborting the distributed transaction is too conservative. One of the major benefits of distributed processing is its robustness to failures, and SEP fails to take advantage of this. We can introduce partial rollback features to prevent the distributed transactions from aborting unilaterally.

1041-4347/00/$10.00 ß 2000 IEEE

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

SEP suffers from another shortcoming in that a distributed transaction may be subjected to starvation. This occurs when a higher-level subtransaction gets aborted repeatedly because of some malicious lower-level subtransaction. While this may be inevitable if we are to guarantee serializability, we may still incorporate forward recovery measures which will prevent starvation, if required, albeit at the expense of serializability. To this end, we propose an advanced secure early prepare commit protocol (ASEP), together with several language primitives to support the protocol. These primitives can be used by a sophisticated programmer to relax consistency, to ensure atomicity and, at the same time, prevent starvation of the distributed transaction. In particular, we offer the programmer a choice to specify in the distributed transaction actions to be taken by each of the participating subtransactions that read low data, in case the subtransaction has released locks prematurely. The choices offered may vary from outright abort of the subtransaction (thereby abort of the distributed transaction) to doing partial rollback so that the distributed transaction can proceed to completion without sacrificing consistency, or doing some kind of forward recovery which may result in execution that is meaningful in a particular application, even though it is not serializable. These primitives allow the distributed transaction to be robust to failures that occur due to broken low-level read locks. The rest of the paper is organized as follows: In Section 2, we define the basic concepts and notation, followed by a brief review of SEP in Section 3. Our system primitives are introduced in Section 4. The basic version of the ASEP protocol is described next in Section 5, followed by examples of distributed transactions that invoke the basic version of ASEP thereby ensuring consistency of the database. Section 6 gives proof that the ASEP protocol in the basic form ensures consistency of the database and, hence, is correct. In Section 7, we describe the advanced version of the protocol together with examples of how commit of distributed transactions can be ensured in our model. Performance of the protocol is studied in Section 8. Finally, we conclude in Section 9.

2

MLS DISTRIBUTED DATABASE MODEL

An MLS distributed database consists of a set N of sites, where each site N 2 N is an MLS database. The sites in the system are interconnected via communication links over which they can communicate. We assume that these links are secure (possibly using encryption); thus, no communication between two sites is subject to eavesdropping, masquerading, replay, or integrity violation. We model an MLS distributed database as a quadruple < D; T ; S; L > , where D is the set of data objects (objects), T is the set of distributed transactions (subjects), S is the partially ordered set of access classes (or security levels) with an ordering relation  (also known as the dominance relation), and L is a mapping from D [ T to S. Security level si is said to dominate security level sj if

881

sj  si and strictly dominate security level sk (denoted by sk < si ) if sk  si and sk 6ˆ si . For every x 2 D, L…x† 2 S, and for every T 2 T , L…T † 2 S. In other words, every data object, as well as every distributed transaction, has an access class associated with it. We extend the mapping L such that it maps each MLS database N to an ordered pair of security classes Lmin …N† and Lmax …N†. Clearly, it should always be the case Lmin …N†; Lmax …N† 2 S, and Lmin …N†  Lmax …N†. In other words, every MLS database in the distributed database has a range of security levels associated with it. For every data object x stored in an MLS database N, Lmin …N†  L…x†  Lmax …N†: Similarly, for every transaction T executed at N, Lmin …N†  L…T †  Lmax …N†: A site Ni is allowed to communicate with another site Nj only if Lmax …Ni † ˆ Lmax …Nj †.1 The reader may refer to [9] for additional details on the MLS distributed database model. Our security policy is based on the Bell-LaPadula model and enforces the following restrictions: .

A transaction T is allowed to read a data object x only if L…x†  L…T †. . A transaction T is allowed to write a data object x only if L…x† ˆ L…T †. Thus, a transaction can read objects at its level or below, but it can write objects only at its level. Although the original ?-property proposed in the Bell-LaPadula model allows transactions to write into levels above their security level, it seems appropriate to disallow transactions that write to higher levels for the sake of database integrity [4], [8]. The trusted DBMSs that are available commercially have the same restriction. In addition to these two requirements, a secure system must guard against illegal information flows through covert channels.

2.1 Distributed Transaction Model For each security level s in the range fLmin ; Lmax g at a particular site, there is one transaction manager (T Ms ) at that level. A user logged in at level s submits a transaction T to T Ms . If T does not require access to remote objects, T Ms simply executes it as a local transaction. If, on the other hand, T is a distributed transaction, T Ms decomposes the distributed transaction T into a collection of subtransactions Ti , each of which inherits the security level of the main transaction T , and forwards each Ti to the appropriate remote MLS system Ni . (It must be the case that Lmin …Ni †  L…Ti †  Lmax …Ni †.) A subtransaction Ti can execute at a site Ni only if .

whenever Ti wishes to read an object x, Lmin …Ni †  L…x†  L…T †, and

1. This assumption is necessary to avoid the cascade vulnerability problem which occurs when a penetrator can exploit the network connections to pass data of a security level d to a user with lower security clearance u, without having to defeat any single component of the system that has an accreditation range great enough to allow users of level u and data of level d on a single system [5], [12].

882

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

Fig. 1. An example history illustrating the problem with EP in MLS systems.

.

whenever Ti wishes to write an object x, L…x† ˆ L…T †  Lmax …Ni †. We model a distributed transaction T as a nested transaction [14]. Nested transactions have a hierarchical grouping structure: Each nested transaction consists of either primitive actions (read or write) or some nested transactions. For simplicity, we assume that a distributed transaction T in our model has only one level of nesting with the transaction T at the top level and each participating transaction Ti at the next level. The toplevel transaction T can also have some read and write operations that are to be executed locally at the originating site. In such a case, those read/write operations are treated as another subtransaction Ti which is executed at the originating site. The top-level transaction T performs the coordination and supervisory functions; it also initiates the atomic commit protocol and will be called the coordinator. Each subtransaction is represented in the commit protocol by a process which we call participant. We have chosen to use the nested structure for two reasons. First, it allows an elegant way to represent asynchronously and independently executing subtransactions. Second, in a nested transaction, subtransactions can fail independently of each other and independently of the containing transaction. This feature allows the possibilities we provide, such as attempting a rollback and reexecution at only one site if there is some kind of failure.

2.2 Secure Concurrency Control Protocol We assume that each transaction manager T Ms uses a secure locking protocol as the concurrency control protocol [11], [7], [6], [1]. These locking protocols have the common feature that whenever a transaction Ti wishes to read (write) a data object x, Ti must first acquire a read lock (write lock) on x. However, Ti must release a read lock on a data object x whenever another transaction Tj such that L…Tj † < L…Ti † requests a write lock on x. We assume that each subtransaction Ti is wellformed according to the requirements of the specific secure

concurrency control protocol. In general, this implies that a subtransaction acquires a lock in the appropriate mode before accessing a data object.

3

SECURE EARLY PREPARE PROTOCOL (SEP)

As we indicated in the introduction, the conventional EP protocol [13], [15] fails in an MLS system since EP requires that no lock can be released by a subtransaction within its window of uncertainty. However, in an MLS environment, read locks on a low-level object have to be released, whenever a low transaction tries to write to the same object. Consider the history in Fig. 1 showing two distributed transactions Low and High such that L…Low† < L…High†. Each distributed transaction consists of two subtransactions: Low1 , Low2 and High1 , High2 with Low1 and High1 executing at Site 1, and Low2 and High2 executing at Site 2, respectively. Among the data objects accessed by Low and High are x and y with L…x† ˆ L…y† ˆ L…Low†. Data object x is at Site 1 while y is at Site 2. The order of execution of each subtransaction is shown in Fig. 1. The event yes in the figure signifies that the subtransaction has completed execution and has sent a yes vote to the coordinator. Note that when w‰xŠ is invoked by Low1 , the operation cannot be delayed waiting for High1 to release the read lock on x. This is in order to avoid a covert channel between the two security levels. Consequently, although High1 is in its window of uncertainty when Low1 requests write lock on x, the read lock on x by High1 has to be released. Basic EP protocol does not take into account that read locks may be released during a subtransaction's window of uncertainty. In this case, EP will commit both distributed transactions High and Low thereby leading to the nonserializable history shown in Fig. 1. The SEP protocol described in [1] tolerates the release of read locks within the window of uncertainty and solves this problem. In particular, in Fig. 1, SEP commits the distributed transaction Low but aborts High and thus prevents the nonserializable history. SEP introduces a

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

883

coordinator, T gets aborted. In the worst case, this may lead to starvation of certain high transactions by malicious low transactions. We feel that such a strategy of aborting the distributed transaction is too conservative. In the following section, we introduce partial rollback features to prevent the distributed transactions from aborting. In fact, our modified commit protocol sends to each low-reading site instructions regarding what to do if it had to release low read locks, instead of simply aborting the distributed transaction.

4

Fig. 2. Example of a distributed transaction.

confirmation phase before the decision phase of EP; in this confirmation phase, SEP finds out if any read locks have been released within a subtransaction's window of uncertainty. If so, the distributed transaction is aborted. The complete description of SEP is as follows: 1.

The transaction manager at the originating site generates subtransactions T1 ; T2 ; . . . ; Tn , and sends them to the participants P1 ; P2 ; . . . ; Pn , respectively. 2. Each participant Pi executes Ti and sends the coordinator C either a yes vote or a no vote. A yes vote is sent if Pi could successfully complete the subtransaction. Additionally, if Ti has read any low data, Pi sends a read-low indicator to C along with the yes vote. 3. If C receives a yes vote from all participants, it checks to see if it has received any read-low indicator. If so, C sends to each participant Pj that sent a read-low indicator a confirm message to verify that it has not released any read locks on the lowlevel data objects prior to receiving the confirm message. 4. If Pj has not released its read locks on any low-level data object prior to receiving the confirm message, it responds with a confirmed message; otherwise, it sends a not-confirmed message. 5. If the coordinator C receives a confirmed message from all Pj s to which C had sent the additional round of messages, then it commits the distributed transaction and sends a commit message to all participants; otherwise, it aborts the transaction and sends abort messages to all participants. Thus, we find that in SEP whenever any of the subtransactions of T releases any read lock on low-level data objects prior to receiving the confirm message from the

SYSTEM PRIMITIVES

As mentioned in Section 2.1, we model a distributed transaction in the form of a nested transaction with one level of nesting. A distributed transaction in our model, is implemented as procedure written in some high-level programming language. This high-level language includes all the familiar constructs for structured programming, including support for conditional statements. We provide a number of linguistic constructs that extend the high-level language to support transaction processing. A programmer can use these primitives as system calls in distributed transactions. The system primitives include the familiar transaction bracketing commands like Begin and End transaction plus a few others which we now describe. A typical distributed transaction in our model is shown in Fig. 2. The main (top-level) transaction is shown on the left, and details of two typical subtransactions are shown on the right. A distributed transaction, submitted by a user, is bracketed by the basic transaction processing system calls Begin_Top_Level_Transaction and End_Top_Level_Transaction. The entire code for the distributed transaction is within these system calls. Each subtransaction is bracketed by the pair of system calls Begin_Local_Transaction and End_Local_Transaction and is identified by a label associated with every Begin_Local_Transaction. The execution of Begin_Local_Transaction initiates the subtransaction at the local site. The environment for the subtransaction is initialized and a transaction identifier is established. The successful execution of the End_Local_Transaction command signifies a request by the participant to the coordinator to initiate the commit protocol. To do this, the participant sends a yes vote to the coordinator. The subtransaction waits at the End_Local_Transaction command until the participant receives a response from the coordinator in the form of an instruction. When the participant has received such an instruction, the subtransaction executes the instruction. If the instruction is to commit or abort, the subtransaction commits or aborts accordingly. For all other instructions, once the execution is complete, the participant replies by a yes vote message or a no vote message depending on the execution termination state of the subtransaction. To specify the termination of a subtransaction, the programmer can use the primitives Commit_Work and Abort_Work in addition to End_Local_Transaction. A Commit_Work or Abort_Work primitive at any point within the body of the subtransaction has the following semantics. If the subtransaction encounters a Commit_Work command, it

884

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

skips the rest of the code in the subtransaction body and executes the End_Local_Transaction primitive instead. As before, this signifies a request by the participant to the coordinator to initiate the commit protocol (i.e., the subtransaction sends out a yes vote to the coordinator). If the subtransaction encounters the Abort_Work command in its execution, it aborts after sending out a no vote. After the coordinator has received vote messages from all participants, the coordinator initiates the commit protocol. If there is even one no vote, the distributed transaction is aborted. If there were subtransactions that read lower-level data, the new system primitive SignalStatus implements the commit protocol. This primitive is one of the five new primitives that we introduce and can be invoked only by the coordinator. By executing the SignalStatus command, the coordinator sends out to each subtransaction the instructions that the subtransaction is expecting while waiting at the End_Local_Transaction command. After the completion of SignalStatus command, the coordinator sends out a commit or an abort message to each participant. The syntax of the five new commands is as follows: 1. 2. 3. 4.

sl ˆ SaveWork…† RollBack(sl) GetSignal‰‰sl1 ! handler1 Š . . . ; ‰s1n ! handlern ŠŠ SignalStatus[repeat TID .. p ˆ)GetSignal‰. . .Š; . TIDq ˆ)GetSignal‰. . .Š until < condition > ] 5. NoSignalServiced Associated with the top-level transaction, there are three system variables that can be accessed by the programmer: The counter variable redoneSignalStatus and the Boolean variables readytoCommit and noearlyLockReleased; their values, however, cannot be modified by a programmer. When the toplevel transaction executes the Begin_Top_Level_Transaction primitive, these three system variables are initialized: redoneSignalStatus is set to zero, and readytoCommit and noearlyLockReleased are set to TRUE. The contribution of these variables to the protocol will be clear when we describe the semantics of the SignalStatus command. Associated with each subtransaction is a counter variable called rollbackCount which is local to the subtransaction. When a subtransaction executes the Begin_Local_Transaction primitive, it initializes its rollbackCount variable to zero. This variable is incremented by one any time and every time the subtransaction is rolled back. By checking this variable, a programmer can determine how many times a particular subtransaction has been rolled back. The execution of the End_Top_Level_Transaction command marks the end of the distributed transaction; the transaction manager for T can now forget about T . In the following, we describe the semantics of each of the five primitives in details and show how the experienced programmer can use them to direct each of the participating low-reading sites what to do in case low-read locks had to be released.

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

4.1 Semantics of SaveWork and RollBack The SaveWork() system call establishes a savepoint which causes the system to record the current state of processing. Each transaction manager writes a savepoint record on the local transaction log, while the process manager saves the current values of any local variables in volatile memory. The SaveWork() call returns to the subtransaction a handle assigned to an identifier sl (called a signal label) which can subsequently be used to refer to that savepoint. Typically, this handle is a monotonically increasing number. The subtransaction can reestablish (return to) any savepoint by invoking a RollBack…sl† command and passing to it the signal label sl of the savepoint that is to be restored. Depending on the application logic, the transaction programmer can decide to return to the most recent savepoint or to any other savepoint. Note that each savepoint established by a subtransaction is local to only that transaction. We assume that the successful execution of the Begin_Local_Transaction primitive establishes the first savepoint for that subtransaction; this first savepoint is referred to symbolically as sldefault . The RollBack…sl† primitive takes as parameter a signal label sl and restores the state of the system to the state at the time of the establishment of the savepoint sl (i.e., the step sl ˆ SaveWork…†). The transaction then restarts its execution from the step following sl ˆ SaveWork(). In other words, the result of the RollBack…sl† command is the execution of a series of undo…opi † operations, the duals of the operations opi . For each operation opi that precedes RollBack(sl) and up to the command SaveWork() corresponding to the signal label sl (but excluding the SaveWork() command), an undo…opi † is executed. The effect of an undo operation is to release any lock that opi acquired on a data object, and remove the result of opi from the system, as if opi was never executed. Consequently, the data objects, as well as the local program variables, are restored to the state at the savepoint sl. Once that state has been restored, the RollBack…sl† call terminates. The transaction is now ready to reexecute starting from the operation that follows the SaveWork() command. Note that if there is a conditional branching command between the sl ˆ SaveWork…† step and the RollBack…sl† step, it may result in a different sequence of commands being executed at this time than was executed initially before the rollback. Fig. 3 shows how the SaveWork() and RollBack…sl† primitives control the flow of a transaction. The original transaction is shown on the left. The Begin_Local_Transaction command establishes implicitly the first save point sldefault . The results of r‰xŠ and w‰yŠ operations are saved as a result of the SaveWork step with signal label sl2 . Since the RollBack command has sl2 as the parameter, the transaction performs undo operations undo…w‰pŠ† and undo…r‰zŠ† in that order. Once this is done, the transaction resumes normal execution with the steps r‰zŠ, w‰pŠ, w‰xŠ, etc. The resulting transaction containing the steps that are effectively executed, is shown on the right. 4.2 Semantics of GetSignal In our protocol, we assume that the lock manager sends a message (signal) to the transaction manager whenever a

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

885

Fig. 3. Use of SaveWork and RollBack primitives.

low-level read lock, held by a high subtransaction, has to be released during its window of uncertainty. The GetSignal system primitive is used by the programmer to specify how such signals are to be handled (or serviced) by the high subtransaction. The GetSignal call has two exit points: A standard one which is the next instruction after the GetSignal and an exceptional continuation which is represented by the expression ‰sl1 ! handler1 Š; . . . ; ‰sln ! handlern Š: Each sli represents a signal label and the corresponding handler represents the code to be executed for this signal label. When a read lock acquired by a high subtransaction Ti on a low data object has to be released, the Lock Manager raises a signal (i.e., sends a message) to the high transaction manager for Ti identifying the low data object in question. Each signal received by the transaction manager indicates a new value for a low data object that has been previously read by Ti . Upon receipt of a signal, the transaction manager locates the savepoint sl that immediately precedes the read of the data object identified by the signal. We say the savepoint sl covers the data object in question. For example, if the signal indicates a new value for the data object x, then the signal label sli established by the step sli ˆ SaveWork…† and corresponding to the last savepoint before the operation ri ‰xŠ, is chosen. If multiple low read locks of Ti are broken, the transaction manager receives multiple signals, one for each broken lock, from the lock manager. The high transaction manager buffers all signals that it receives from the lock manager for each transaction Ti . Later on when Ti invokes a GetSignal call, the transaction manager considers all the signals it has buffered for Ti , and selects one signal to be serviced as follows: It selects a signal label that covers all the low reads with broken read locks (i.e., selects the signal

label that precedes all other signal labels that are generated due to broken read locks). To illustrate how the transaction manager selects a signal to service, consider the transaction fragment shown in Fig. 4. In the figure, a high transaction Ti performs three low read operations ri ‰pŠ, ri ‰qŠ, and ri ‰sŠ. If the low read lock on p is broken, the signal selected by the transaction manager is slp since the signal label slp covers ri ‰pŠ. Similarly, if read locks on q and s are broken, the transaction manager will select signal slq as the signal label slq covers ri ‰qŠ and ri ‰sŠ. If all three low read locks are broken, the signal slp will be selected for servicing by the transaction manager, since it covers all three objects. When a signal sli is selected for servicing, the code for the corresponding handler, handleri , is executed. The programmer can explicitly specify the default invocation of

Fig. 4. Choosing a signal to be served.

886

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

GetSignal by using the notation GetSignal‰! handlerŠ. The default invocation does not indicate any signal label. The same handler is used to service any signal that has been raised. A special case of the default invocation is GetSignal‰! RollBackŠ which does not specify any signal label for the RollBack command. If there is any signal to be serviced, this particular invocation rolls back the transaction Ti to the savepoint corresponding to the signal label that have been signaled by the lock manager. If no savepoint has been explicitly established in the transaction, then this default invocation rolls back Ti to the default savepoint sldefault coinciding with the Begin_Local_Transaction. Referring to Fig. 4 the GetSignal call in the figure can be replaced by the default invocation GetSignal‰! RollBackŠ and the effects will be the same. This is assuming that there is no low read operation that precedes ri ‰pŠ in the figure. It should be noted that the GetSignal call is nonblocking, i.e., the call does not wait for the arrival of a signal. If a signal is already available, it is serviced, otherwise, no action is taken.

4.3

Semantics of SignalStatus and NoSignalServiced The SignalStatus primitive forms the heart of our commit protocol. When a programmer uses this command, the system will embark on the secure commit protocol. The SignalStatus primitive is always invoked by a toplevel transaction at the coordinating site. The body of the command consists of a Repeat . . . Until loop. This means that the body is executed at least once. Within the loop, there are a number of steps of the form TIDi ˆ)GetSignal‰. . . ]. Each of these steps represents a concurrent thread of operation. When the SignalStatus command is executed, the following events occur at the coordinator: 1. 2.

3.

For each step of the form TIDi ˆ)GetSignal‰. . .Š within the body of the loop, the coordinator forks a concurrent thread of operation. Each of these concurrent threads sends a message to the corresponding subtransaction TIDi . By this message, the subtransaction TIDi is asked to execute a GetSignal, with the handler specified in the GetSignal call. The thread then waits for a response to come from the subtransaction. Upon receiving the message from the coordinator, the subtransaction TIDi executes the GetSignal call as if it has been locally invoked. a.

b.

If there is no signal to be serviced (which implies that no low read lock got broken prematurely), the participant sends a NoSignalServiced message to the coordinator and waits for a response from the coordinator. If there is a signal to be serviced (which means that one or more low read locks got broken prematurely), the subtransaction executes the handler of the GetSignal. i.

After the subtransaction executes the handler successfully and reaches End_Local_Transaction, it sends a yes vote to the coordinator.

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

ii.

4.

If the subtransaction is unable to execute successfully it sends a no vote to the coordinator. Then, the subtransaction begins its wait for a response from the coordinator.2 The thread at the coordinator comes out of its wait state when the thread receives the response from the subtransaction and updates the values of the global variables noearlyLockReleased and readytoCommit as follows:

If response from subtransaction is NoSignalServiced then noearlyLockReleased = noearlyLockReleased ^TRUE else noearlyLockReleased = FALSE If response from subtransaction is yes vote then readytoCommit = readytoCommit ^ TRUE else readytoCommit = FALSE endif endif 5.

When all votes have been received, first the value of the variable noearlyLockReleased is tested. If it is TRUE, the coordinator commits the distributed transaction, and informs all participants of the commit decision. If the variable is FALSE, the variable readytoCommit is tested. If it is FALSE (corresponding to the case when one or more participants respond with no votes), the coordinator aborts the distributed transaction and informs all participants accordingly. If readytoCommit is TRUE, the condition portion of the Repeat...Until loop is checked. If the condition is false, the Boolean variables readytoCommit and noearlyLockReleased are reset to TRUE, the counter variable redoneSignalStatus is incremented by one, and the loop is reexecuted starting from Step 2 above. If, on the other hand, the condition evaluates to true, the coordinator aborts the distributed transaction and sends an abort message to each participant. Note that the programmer can utilize the redoneSignalStatus variable within the condition portion of the loop only to specify the number of times the loop is executed before the distributed transaction is aborted. If the programmer wants to commit a distributed transaction after executing SignalStatus a fixed number of times (as specified by the value of the variable redoneSignalStatus), then the programmer should use the primitive NoSignalServiced in 2. Note that the handler for the GetSignal may contain a RollBack command. In this case, after the successful execution of the handler, the subtransaction will start executing the code following the savepoint specified in the RollBack. During the course of this execution, the subtransaction may encounter Abort_Work, Commit_Work, or End_Local_Transaction. If it encounters Abort_Work, a no vote is sent. In the other two cases, the subtransaction sends a yes vote and waits for response from the coordinator.

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

the handler portion of the GetSignal. When this primitive is executed by a subtransaction, the participant sends a NoSignalServiced message to the coordinator even if a low read lock is broken within the window of uncertainty and, consequently, a signal needs to be serviced. An example usage of this primitive will be shown later in Section 7.1. Now, we present the Advanced Secure Early Prepare (ASEP) commit protocol. ASEP comes in two different flavorsÐthe basic one which ensures consistency of the database and the advanced one which ensures commit of the distributed transaction. The programmer uses the language primitives to control the behavior of the algorithm; essentially, the parameters passed to the SignalStatus primitive determines what behavior ASEP will exhibit. If the SignalStatus primitive contains well-formed GetSignal calls (defined subsequently) as parameters and complies with the requirements of an asep-well-formed distributed transaction, then ASEP ensures consistency of the database; in other cases, the protocol tries to ensure the commit of high-level transactions even at the expense of consistency. We would like to emphasize here that, although a programmer can take the initiative to ensure an asep-wellformed transaction, by default the system implements such a transaction. Consequently, consistency of the database is the default behavior. For the description of the protocol, we will assume that a secure locking protocol is used to achieve concurrency control. This locking protocol is such that a subtransaction is required to acquire a lock in the relevant mode on a data object, prior to accessing it. If a higher-level subtransaction has a read lock on a lower-level data object when a lowerlevel subtransaction requests a write lock on the same item, the higher-level subtransaction releases the read lock.

5

THE ASEP PROTOCOL: BASIC VERSION

Before we describe the basic protocol, we need some definitions. Definition 5.1. Let T be a distributed transaction comprising of subtransactions T1 ; . . . Tn . If T includes a GetSignal call of the form Ti ˆ)GetSignal‰‰slp ! handlerp Š . . . ‰slq ! handlerq ŠŠ; where Ti is a lower reading subtransaction then the GetSignal invocation will be well-formed if: 1.

2.

For every low read operation ri ‰xŠ by Ti , there is a ‰slx ! handlerx Š within the GetSignal call such that the signal label slx covers the low read operation ri ‰xŠ and The handler handlerx is either RollBack…slx † or an Abort_Work command.

To program a well-formed GetSignal call for a subtransaction, the programmer needs to incorporate the required handler for every low read operation of the subtransaction (as any low read operation in the subtransaction may potentially be signaled). Not only that, the programmer also has to ensure that every low-level read operation is covered by a savepoint.

887

Fig. 5. Incorporating multiple savepoints and partial rollbacks of subtransactions.

Recall that the default savepoint, sldefault , established with the Begin_Local_Transaction call covers every low read operation. Hence, a simple way to ensure a well-formed GetSignal is to have a rollback to this savepoint regardless of the particular signal. This is achieved by the following call: GetSignal‰! RollBack…sldefault †Š. The advantage of this invocation is that the programmer does not have to specify any savepoint explicitly in the subtransaction body. However, the disadvantage is that it will always rollback the subtransaction completely. Establishing more than one savepoint may reduce the cost of rollbacks. The simplest way to ensure well-formed GetSignal invocation which takes advantage of using multiple savepoints within the subtransaction is to have the default invocation viz., GetSignal‰! RollBackŠ. A third way by which a programmer can ensure a wellformed GetSignal is as follows: Suppose a subtransaction Ti contains the low read operations ri ‰xŠ, ri ‰yŠ, and ri ‰zŠ (in this order). The programmer can precede each of these low read operations by a sl ˆ SaveWork…† command, and specify handlers for each of the signal labels slx , sly , and slz in the SignalStatus command, as shown in Fig. 5. Depending on the signal to be serviced, the subtransaction can rollback to different savepoints. This enables the programmer to decide how many savepoints to use thereby trading off the cost of establishing savepoints and performing rollbacks. Definition 5.2. A multilevel secure distributed transaction, T , is asep-well-formed if it satisfies the following conditions: 1.

Each subtransaction Ti is well-formed according to the secure concurrency control protocol used.

888

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

Fig. 6. Finite state automata for coordinator and participant in classical EP.

TABLE 1 Symbols Used in Figs. 6 and 7 and Their Meanings

2.

Every low reading subtransaction Ti is represented in the SignalStatus primitive and all the GetSignal calls are well-formed.

To describe all the details of the ASEP protocol, we model the execution of the commit protocol at each site as a finite state automaton. The coordinator or a participant moves from one state to another by receiving and sending messages over the network. To introduce the notation, we present first the classical early prepare commit protocol as a finite state automaton. Fig. 6a represents the coordinator while Fig. 6b represents a participant. Labeled circles in the state transition diagrams indicate intermediate states, while labeled rings indicate final states with label a denoting abort

and label c denoting commit. Labels on the arcs are in the form of fractions; the numerator of the label indicates either the messages that must be received for the state transition to occur or a logical precondition that must be satisfied to enable the state transition; the denominator of the label indicates the messages sent as a result of the state transition (see Table 1). Consider the finite state automaton in Fig. 6a. When the coordinator is in the initial state s1, it waits for a request from the user to execute a distributed transaction; this is represented by the ªrequestº message in the label for the edge s1 ! s2. The receipt of the message triggers the state transition of the coordinator; the coordinator in

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

turn sends out the messages T1 . . . Tn , which denotes the subtransactions distributed to the various participants along with requests for votes. From state s2, the coordinator can move to either state a (if at least one no vote is received from the participants) or to state c (if yes votes are received from all participants). If the coordinator moves to state a, it sends out message ªabortº to all participants else it moves to state c by sending out message ªcommit.º A similar notation in Fig. 6b describes the corresponding state transitions of the participants. The finite state automaton in Fig. 7a represents the coordinator's execution in the basic ASEP protocol. Fig. 7b gives a low-reading participant while Fig. 7c gives a nonlow reading participant. We now describe the protocol with the help of these finite state diagrams. Note that, while discussing states for the coordinator, we will be referring to the Fig. 7a while for participants we will refer mostly to Fig. 7b.

c.

4.

2.

3.

b.

c.

Coordinator: s1 ! s2. The coordinator C generates subtransactions T1 ; T2 ; . . . ; Tn . The security level of each Ti is same as T , viz., s. C forces a membership log record and forwards the subtransactions to participants P1 ; P2 ; . . . ; Pn , respectively, along with requests for votes. This is represented by the state transition s1 to s2 in Fig. 7a Participant: s1 ! s2, s1 ! a. An s-level participant Pi which is initially in state s1 in Figs. 7b and 7c, receives the subtransaction Ti . Pi proceeds to acquire the pertinent locks and then execute the subtransaction. If the subtransaction is able to complete successfully, Pi forces a prepare log record, and sends a yes vote to the coordinator C. At this point, the participant moves to state s2. If, on the other hand, the subtransaction is unable to complete successfully, it is aborted. In this case, Pi sends a no vote to the coordinator C and moves to the final abort state a. Coordinator: s2 ! a, s2 ! c, s2 ! s3. When the coordinator C has received either a yes vote from each participant or at least one no vote from any participant,3 it executes one of the following steps. a.

b.

If there is a no vote, the coordinator aborts the distributed transaction by sending an abort message to each participant. This is shown by the state transition s2 ! a for the coordinator. If all votes are yes votes, the coordinator checks if there was any subtransaction that read low data. If there is no such subtransaction, the coordinator commits the distributed transaction T , forces a commit record, and then sends commit messages to all the participants. The coordinator moves from state s2 to state c in the Fig. 7a.

3. We assume that if a vote is missing, that is, it does not arrive after a time out period, it is considered to be a no vote.

If all votes are yes votes and there is at least one subtransaction that read at lower level, the coordinator executes the SignalStatus primitive that invokes a GetSignal‰. . .Š at each low reading participant Pi . For nonlower reading participants, the coordinator does not send out any message at this time. The state transition s2 ! s3 in the finite state automaton for the coordinator represents this state change. Participant: s2 ! a, s2 ! c, s2 ! s2, s2 ! s3. Depending on the message received from the coordinator, a participant performs the following steps. a.

Algorithm 5.1 ASEP: Basic Version. A user logged in at security level s initiates an asep-well-formed distributed transaction T at a particular site. The level of the distributed transaction becomes s. A coordinator process C is created at this site corresponding to the transaction T . 1.

889

If the participant receives an abort message, the participant writes an abort log record and aborts the subtransaction. This is shown by the transition from state s2 to state a in both the Figs. 7b and 7c. If the participant receives a commit message, it writes a commit log record for the subtransaction and commits the subtransaction. The corresponding state transition is s2 ! c. A low reading participant which receives the GetSignal invocation executes the call and, depending on the result of the execution, sends one of the following three messages to the coordinator: i.

5.

no voteÐif either the handler was an Abort_Work or the result of servicing the signal was unsuccessful. In such a case, the participant aborts the subtransaction and moves from state s2 to state a. ii. NoSignalServicedÐif the subtransaction did not release any low read lock prematurely and, consequently, did not service any signal. The participant remains in state s2. iii. yes voteÐIf the subtransaction did release a lock prematurely, the handler was not an Abort_Work command and after the subtransaction executes the handler successfully, it reaches End_Local_Transaction. In this case, the low reading participant moves to state s3 after forcing a commit record. d. If the participant is nonlower reading, it does not receive any message from the coordinator; consequently, it does not change state and remains in state s2. Coordinator: s3 ! a, s3 ! c, s3 ! s3. On receipt of the messages, the coordinator performs the following steps: a.

b.

If the coordinator receives even one no vote from the participants, the coordinator aborts the distributed transaction. It forces an abort record and sends abort messages to the participants. Here, the coordinator moves from state s3 to state a. If the coordinator receives NoSignalServiced from all low reading participants, it commits the distributed transaction, forces a commit

890

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

Fig.7 . Finite state automation in AESP protocol: Basic version. (a) Coordinator. (b) Lower Reading Participant. (c) Nonlower Reading Participant.

record, and sends commit messages to all participants. In this case, the coordinator's state changes from s3 to c.

c.

For the other case, which involves one or more yes votes and the other NoSignalServiced messages, the coordinator evaluates the condition in the

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

Fig. 8. Simulating SEP in ASEP.

body of the Repeat...Until loop of the SignalStatus command. i.

6.

If the condition evaluates to false, the coordinator reexecutes the body of the SignalStatus primitive. This results in the coordinator invoking GetSignal at each of the low reading participants. This is shown in the finite state automaton by the coordinator remaining in state s3. ii. If the condition evaluates to true, the coordinator aborts the distributed transaction by forcing an abort record and informing the participants of the decision. This is the case where the coordinator goes to state a from state s3. Participant: s3 ! a, s3 ! s2, s3 ! s3. If the coordinator reexecutes the SignalStatus primitive, the low reading subtransaction reexecutes the GetSignal call. The participant may be in state s2 or s3 at this point. If it is in state s2, the Step 4 above is reexecuted. Otherwise, if the participant is in state s3, then, depending on the result of the execution of the GetSignal, the participant sends one of the following messages: a.

7.

no voteÐThe participant aborts and goes from state s3 to state a. b. NoSignalServicedÐThe participant goes to state s2 from s3. c. yes voteÐThe participant remains in state s3. The protocol continues execution from step 5 above.

5.1 Ensuring Consistency under ASEP We now consider three invocations of the SignalStatus primitive for which the ASEP protocol basic version ensures consistency. 1.

The Repeat...Until loop in the SignalStatus command is executed once. If all the low reading participants send a NoSignalServiced message to

891

Fig. 9. Executing Repeat...Until loop again and again until all participants respond with NoSignalServiced messages.

the coordinator, then the distributed transaction commits, otherwise, it aborts. Note that, in this case, ASEP reduces to SEP [1].) 2. The Repeat...Until loop in the SignalStatus command is executed over and over again with each of the low reading participants rolling back when servicing a signal, and reexecuting until all of them respond with NoSignalServiced messages. 3. An exit condition for the Repeat...Until loop is specified that makes this loop reexecute a finite number of times. If all participants respond by NoSignalServiced during the same pass through the loop, the distributed transaction commits. Otherwise, if the exit condition is satisfied and there is at least one participant that does not reply with a NoSignalServiced the distributed transaction aborts. Note that Cases 1 and 2 are variations of Case 3. Specifically, for Case 1, the exit condition for the Repeat...Until allows only one execution of the loop. For Case 2, the exit condition is False. Although such exit condition implies that the Repeat...Until loop can potentially execute infinite number of times, we assume that special external measures can be taken (for example, by the security officer) to ensure that the distributed transaction will eventually commit. For proving the correctness of the basic version of the ASEP protocol, we will consider only Case 3 in Section 6. The program fragments for each of the three aforementioned cases are given in Figs. 8, 9, and 10. For simplicity, we assume that the distributed transaction T consists of two subtransactions T1 and T2 , both of which read lower-level data. Furthermore, we assume that the only savepoint that is established in each subtransaction is the default savepoint sldefault resulting from the execution of the primitive Begin_Local_Transaction. Thus, if a subtransaction has to rollback, it does so by rolling back to the default savepoint. As discussed earlier, we can easily eliminate this assumption by establishing more savepoints (such that there is at

892

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

Fig. 10. Allowing at most one of the subtransactions to rollback its maximum number of specified times.

least one savepoint that covers all low reads) and allowing the subtransactions to rollback to different savepoints. Note that in Fig. 8, the Repeat...Until loop in the SignalStatus command will be executed once and only once. Since the handler for the GetSignal command in each subtransaction specifies an Abort_Work command, the coordinator aborts if any of the participants services a signal (i.e., there is a broken lock). If none of the participants has to service a signal, (i.e., each Ti responds with NoSignalServiced) only then will the coordinator issue a commit. In all other cases, the coordinator will issue an abort. In Fig. 9, first of all note that since the programmer has specified the default invocation of GetSignal, whatever be the signal selected to be serviced, the subtransaction will always RollBack to the default savepoint. In this example, we could have provided sldefault ! RollBack…sldefault † as the parameter of each GetSignal call. Furthermore, if there were a number of savepointsÐone for each low read operationÐ we could have written the code as discussed previously (i.e., have a slx ! RollBack…slx † for each slx ). The observation here is the Repeat . . . Until loop which continues forever. The only way the coordinator can come out of this infinite loop is if both T1 and T2 respond with NoSignalServiced messages in the same round of message exchange; in other words, when neither T1 nor T2 has released a low read lock prematurely and both wants to commit, only then can the coordinator exit from this infinite loop. In Fig. 10, the programmer uses the counter variable rollbackCount which was introduced in Section 4. Recall that this counter variable is associated with each subtransaction and is local to the particular subtransaction. When a subtransaction commences execution, its rollbackCount variable is initialized to zero, and the counter gets

incremented by one everytime the subtransaction rollbacks, whether partially or completely. Note that, allowing the value of the counter variable redoneSignalStatus to go up to ten, ensures that at most one of the participants is allowed to rollback (if required) to its maximum specified times. If a subtransaction has rolled back its specified number of times and still has to service a signal, it executes an Abort_Work which aborts the subtransaction.

6

CORRECTNESS

OF THE

BASIC VERSION

OF

ASEP

We now prove the correctness of the basic version of the ASEP protocol for the case where the distributed transaction is asep-well-formed. We also assume that the SignalStatus primitive is reexecuted a finite number of times such as when the condition in the SignalStatus primitive is redoneSignalStatus  n, n > 0. Like other commit protocols, ASEP is correct if the following two conditions are satisfied: .

Either all participants and the coordinator of a distributed transaction commit or they all abort, and . ASEP maintains the serializability of the distributed transaction. To show that the coordinator and all participants go the same way (i.e., they all commit or abort), we need to show: 1. 2. 3.

Participants can reach exactly one of two decisionsÐcommit or abort; A participant cannot reverse its decision after it has reached one; All participants that arrive at a decision following the protocol, arrive at the same decision;

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

4.

The commit decision can be reached only if all participants decide to commit; 5. If all participants decide to commit and there are no failures, then the decision will be to commit; and 6. At any point in the execution, if all failures that the protocol is designed to tolerate are repaired and no new failures occur, then all participants will eventually reach a decision. To prove the correctness of the ASEP protocol basic version, we first show that for an asep-well-formed distributed transaction that commits, the coordinator and the participants all go the same way; that is, the coordinator and the participants either all commit or all abort. Next, we prove that an asep-well-formed distributed transaction is two-phased. This leads us to conclude that multilevel histories in which the distributed transactions commit by ASEP protocol, are serializable. Theorem 6.1. Given an asep-well-formed distributed transaction T , the ASEP protocol ensures that either the participants and the coordinator of T all commit or they all abort. Proof. Let us consider the case when there are only nonlower-reading subtransactions. Referring to Figs. 6b and 6c, we find that the finite state automaton for non-lowerreading participants in ASEP is exactly the same as the participants in classical EP. Also, if there are no subtransactions that read data at lower levels, then the finite state automaton for the coordinator will not have the state s3 in Fig. 7a and will be exactly the same as that in classical EP (Fig. 6a). Hence, ASEP is correct when all subtransactions read data at their security levels only, as ASEP reduces to EP. Let us consider the case when all subtransactions read at lower security levels. Refer to Figs. 7a and 7b. Notice that, for both the coordinator, as well as the participant, the possible final states are either a (abort) or c (commit). Since there are no edges out of these final states, we conclude that: .

Participants and coordinator can reach exactly one of two decisionsÐabort or commit, and . a participant cannot reverse its decision after it has reached one. Further, a participant can commit only if the coordinator sends the commit message. From Fig. 7a, we find that the coordinator can send a commit message to all participants only after the coordinator has received NoSignalServiced from all participants. The sending of a NoSignalServiced message represents a decision by the participant to commit and always takes the participant to the prepared-to-commit state s2. This implies that all participants that receive a commit message are in the same state which is state s2. Thus, we can conclude that: .

All participants that arrive at a decision following the protocol, arrive at the same decision, and . the commit decision can be reached only if all participants decide to commit. Moreover, referring back to Fig. 7a, if the coordinator receives NoSignalServiced from all low reading participants (the coordinator is in state s3), then the only state that the coordinator moves to is the commit state; at that point, it responds by a commit command to the

893

participants. If there are no failures, then all participants receive the commit command from the coordinator. The only state a participant can move to is the commit state. Thus, we can conclude that .

If all participants decide to commit and there are no failures, then the decision will be to commit. There are four places in ASEP where a process (participant or coordinator) is waiting for a message: in the beginning of Steps 3, 4, 5 and 6. In Step 3, the coordinator is waiting for a yes or no from all the participants. At this stage, the coordinator has not yet reached any decision. According to the protocol, the coordinator waits for a time out period to receive all messages. Any missing message after the time out period is considered a no vote and the coordinator aborts the transaction in that case. In Step 4, a participant p that voted yes is waiting for an abort or SignalStatus command from the coordinator. If the communication with coordinator is lost (either communication failure or the coordinator is down or the participant was down when the coordinator sent the message), the participant remains blocked until communication can be reestablished. At that point, the participant approaches the coordinator for action to take. If the coordinator has not already timed out waiting for a response for its last command, it looks at the membership log record that it has forced at the very beginning and reissues the appropriate command to the participant. The participant can proceed from there. If, on the other hand, the coordinator has timed out and aborted the transaction, it finds from its forced log record the decision and asks the participant to abort. In Step 5, the coordinator is waiting for a no message or a yes message or a NoSignalServiced message. If the message did not arrive after a time out period due to communication failure or failure of a participant, the coordinator assumes a no vote and aborts the transaction. If, on the other hand, it was owing to a failure of the coordinator when a response was sent, the coordinator, after recovering, resends the last issued command and waits for response. In Step 6, a participant that sent a yes message or NoSignalServiced is waiting for a commit, or abort, or SignalStatus command from the coordinator. The participant remains blocked until communication is reestablished with the coordinator. At that point, the coordinator either direct the participant to abort or reissues the command, depending on whether the coordinator has timed out. Thus, we conclude that: .

At any point in the execution, if all failures that the protocol is designed to tolerate are repaired and no new failures occur, the participants will eventually reach a decision.

Finally, the above reasoning can be also applied to the case when there are a combination of lower-reading and non-lower-reading subtransactions and we conclude that ASEP ensures that either the coordinator and all participants commit or they all abort. u t

894

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

So far, we have shown that the participants, as well as the coordinator of any distributed transaction committing with ASEP, go one way, that is, either all of them commit or all abort. In the following, we show that histories of asepwell-formed distributed transactions are serializable.

Proof. We consider two cases:

2.

Suppose that none of the subtransactions of T reads data objects at security levels lower than that of T . In that case, ASEP behaves exactly like the classical early prepare commit protocol in a nonsecure environment. Each participant holds on to all acquired locks throughout its window of uncertainty and up to its commit time. Consequently, T is two-phased. Suppose that all subtransactions of T read data at lower security levels. Consequently, these subtransactions have to execute GetSignal commands. We have two cases: a.

b.

None of the lower reading subtransactions had to release their low read locks prematurely within their windows of uncertainty and all of them reply by NoSignalServiced. In this case, the distributed transaction commits and all participants hold on to all of their locks until commit time. Hence, the committed transaction T is two-phased. Some of the lower reading subtransactions had to release their low read locks prematurely. If any of these low reading subtransactions executes an Abort_Work command as part of servicing a signal, then the distributed transaction is aborted. Otherwise, everytime a subtransaction performs a rollback to the savepoint sl and reexecutes, the effect is the same as that of the subtransaction performing the operations following the savepoint sl for the first time. This is because, during the execution of the RollBack…sl† command the steps between the savepoint denoted by sl and the RollBack are undone; these steps do not play any part in the committed history. Now, the rollbacks and reexecutions may continue many times over. However, the protocol guarantees that there will be a time when either the maximum permitted number of rollbacks as determined by the value of the condition in the SignalStatus command is reached, or all low reading participants respond by NoSignalServiced. In the former case, the distributed transaction is aborted and, hence, does not affect the committed projection of the history. Consider the latter case. Let t0 be the time when the participants received the current set of GetSignal commands from the coordinator in

NO. 6,

NOVEMBER/DECEMBER 2000

whose response the participants have responded with NoSignalServiced. Let ti be the time when a low reading participant Pi last responded to the coordinator's GetSignal command prior to the current response of NoSignalServiced. Consider the instance t ˆ minfti ; 1  i  ng, where n is the number of low reading participants. Clearly, t < ti . Since the low reading participants has responded by NoSignalServiced, it is true that between t and t0 no participant has released any read lock. Moreover, after t0 no participant will acquire any lock even though a subtransaction is forced to release a low read lock. Hence, the distributed transaction T is two-phased. u t

Lemma 6.1. If the ASEP protocol reaches a commit decision for the asep-well-formed distributed transaction T , then T is guaranteed to be two-phased. 1.

VOL. 12,

Since asep-well-formed distributed transactions are twophased, the following theorem holds. Thereom 6.2. Given a history H of asep-well-formed distributed transactions. If the basic version of the ASEP protocol is used for committing these transactions, then H is serializable. The above discussions conclude that the ASEP protocol basic version ensures consistency of the database. We now describe the advanced version of the protocol. Recall that the advanced version emphasizes commit of the distributed transaction. To invoke the advanced version, the programmer needs to be aware of weaker correctness criteria (if any) allowed by the particular application. This is because the advanced version of ASEP ensures commit possibly at the expense of correctness.

7

THE ASEP PROTOCOL: ADVANCED VERSION

For the advanced version, the criterion that the distributed transaction be asep-well-formed, is relaxed. This version allows advanced features like partial rollback and forward recovery. As in the ASEP basic version, we will refer to the Figs. 7a and 7b for state transitions of coordinator and participants. Algorithm 7.1 ASEP: Advanced Version. Steps 1-4b in general are the same as that in the basic version of the protocol. The only difference is that the SignalStatus command need not satisfy the requirements of an asepwell-formed distributed transaction. 4.

Participant: s2 ! a, s2 ! s2, s2 ! s3. A low reading participant that receives a GetSignal call executes the handler in the call. The difference with respect to the ASEP basic version is that a low-reading participant may not receive a GetSignal invocation and the GetSignal call may not be well-formed. In the former case, the low reading participant behaves exactly in the same manner as a non-low reading participant. In the latter case, the handler in the GetSignal call is any piece of code supplied by the programmer. Specifically, the handler can be one of the following three:

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

895

Fig. 11. A distributed transaction in which Repeat...Until loop is executed once before committing.

c.

5.

6.

Abort_WorkÐThe reply from the participant is a no vote, indicating a decision to abort. The participant moves to state a. d. NoSignalServiced/Commit_WorkÐIn this case, even if the subtransaction released a lock, the subtransaction does not service the signal; instead, the participant replies with the message NoSignalServiced (remains in state s2 or an yes vote (goes to state s3). e. Any piece of codeÐIf such code does not contain a RollBack command, the code initiates a forward recovery; on the other hand, it may contain RollBack commands which perform rollback operations. However, these RollBack commands may rollback the subtransaction to various portions of the subtransaction bodyÐnot necessarily to the savepoint that covers the low reads that are signaled. The low reading participant executes the GetSignal call and the associated code and sends a yes or no vote to the coordinator. If the participant sends a yes vote, it moves to state s3. Otherwise, it aborts the substransaction. Coordinator: s3 ! a, s3 ! c, s3 ! s3. The coordinator's response to the replies from the participants is the same as that in ASEP basic version corresponding to Step 5(a,b,c). Participant: s3 ! a, s3 ! s2, s3 ! s3. As in the ASEP basic version Step 6, if the coordinator reexecutes the SignalStatus command, the low reading subtransactions named in the SignalStatus reexecutes the GetSignal calls. The participant can be in state s2

or state s3 at this point. If it is in state s2, the execution of the participant follows Step 4 above. Otherwise, if the participant is in state s3, it sends one of the following responses depending on the result of execution of the GetSignal: a.

no voteÐThe participant aborts and goes from state s3 to state a. b. NoSignalServicedÐThe participant goes from state s3 to state s2. c. yes voteÐThe participant remains in state s3 7. The protocol continues execution from Step 5. Note that this version of the algorithm is very similar to the basic version. The only difference is that the basic version has very specific signal handling features, whereas this version does not. In the following, we give some examples of how commit is ensured by the protocol.

7.1 Ensuring Commit under ASEP In this section, we give two examples to illustrate how it is possible to commit distributed transactions under ASEP even if subtransactions release their low-level read locks prematurely. We assume that there are two sites, A and B. Site A stores data objects q; s; x; y and z with L…x† ˆ L…z† ˆ High and L…q† ˆ L…s† ˆ L…y† ˆ Low. Site B stores the data objects m; n; o and p w i t h L…o† ˆ L…p† ˆ High and L…m† ˆ L…n† ˆ Low. TA denotes the subtransaction to be executed at site A, while TB represents the subtransaction destined for site B. Example 7.1. Consider the distributed transaction given in Fig. 11. Since only subtransaction TA reads low data, the

896

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

Fig. 12. A distributed transaction in which Repeat...Until loop is executed multiple times.

SignalStatus command contains code for TA only. TA contains three low read operations, viz., r‰sŠ, r‰yŠ, and r‰qŠ. If read lock on s is broken, then the signal raised will be sldefault (which was established when the Begin_Local_Transaction command in TA was executed). The signal will be sl2 if the lock on y is broken, and it will be sl3 if the lock on q is broken. The programmer has chosen to use the default invocation of GetSignal but with a condition associated. Thus, if the condition is satisfied, the effect of the GetSignal call will be the same as GetSignal‰! RollBackŠ; otherwise, it will be GetSignal‰! NoSignalServicedŠ. In the latter case, for all signals raised, the participant replies with NoSignalServiced. Also, the specific values used for the variable rollbackCount and redoneSignalStatus ensures that TA is allowed to perform one RollBack before the distributed transaction is committed. Before redoneSignalStatus can be 2, the value of the variable rollbackCount with TA will be greater than 1 and, even if TA has to service a signal, it will send a NoSignalServiced and the coordinator will commit. Note that the distributed transaction in this example is not asep-well-formed. This is because the GetSignal call in the SignalStatus invocation is not well-formed. However, if the distributed transaction commits after the first pass through the loop, then the distributed transaction will be two-phased. While if it goes

through the second pass, the distributed transction may or may not be two-phased. Example 7.2. Consider now the distributed transaction shown in Fig. 12. Since both subtransactions TA and TB read lower-level data, signal handlers have been defined for both of them within the SignalStatus command. TB reads low data objects n and m. The read of n is covered by the signal label sldefault , while sl2 covers the read of m. The programmer has specified a forward recovery operation r‰nŠ, w‰oŠ, RollBack…sl2 † as the handler for sldefault . Thus, if r‰nŠ is signaled, the subtransaction will first read n and then write data object o before performing a rollback to savepoint sl2 . Note that this is different from rollback to savepoint sldefault and reexecution from that point because the operations between r‰nŠ and w‰oŠ are not reexecuted in this case. Further note that no handler has been specified for signal label sl2 . Consequently, if r‰mŠ is signaled, the participant will reply by NoSignalServiced. A typical scenario for the execution of the SignalStatus is as follows: The first time through the loop, suppose TA services a signal and sends a yes response while TB sends a NoSignalServiced response to the coordinator. At the end of this execution, redoneSignalStatus becomes 1. Also, at this stage, the value of noearlyLockReleased is FALSE, and that of readytoCommit is TRUE. Consequently, the loop is

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

897

Fig. 13. Messages exchanged over the network in ASEP.

executed a second time. During this execution, suppose TB services a signal, while TA sends a NoSignalServiced response. As a result, redoneSignalStatus will have a value of two, noearlyLockReleased will be FALSE, and readytoCommit will be TRUE. This will make the loop execute a third time. If during this third execution of the loop both TA and TB send NoSignalServiced messages, then the distributed transaction will go ahead and commit. Notice that the exit condition of the Repeat...Until loop allows the loop to execute a maximum of six times, before the distributed transaction aborts. Of course, if either TA or TB sends a no vote after handling the signals, the distributed transaction will abort earlier. As a last remark, note that the distributed transaction is not asepwell-formed. This is due to the fact that neither the GetSignal invocation for transaction TA or that for TB are well-formed. The handler in the GetSignal invocation for TA will not always rollback the subtransaction to a savepoint that covers the signaled read operation. As for the GetSignal invocation for TB , it is not of the form that ensures well-formedness.

8

PROTOCOL EVALUATION

We evaluate the ASEP protocol basic version with the assumption that protocol will eventually commit a distributed transaction after a finite number of rounds of message exchange. If we compare the number of messages required by ASEP to that required by EP, EP always requires about 4n messages (where n is the number of participants), while ASEP requires 4n messages at the minimum when there are no low-reading participants. If there is even one low reading transaction, at least one extra round of messages is required between the coordinator and those nodes where the participants have read data from lower levels (assuming consistency is required). ASEP at its best, therefore, has the same message complexity as the

conventional 2PC protocol (viz. 6n messages) when there are low reading subtransactions. In the following, we try to estimate the number of messages involved in the ASEP protocol. We refer to Fig. 13 for this analysis. We assume that the distributed transaction T commits. Let the number of subtransactions in the distributed transaction be n with the number of subtransactions that read lower data being nlow and the subtransactions that read data at the same level being nsame . Clearly, n ˆ nlow ‡ nsame . From Fig. 13, we find that between the coordinator and each participant, there are two rounds of message exchanges that are compulsory, i.e., a total of four messages. These are the following rounds: 1.

The first round of message exchange involves the coordinator sending out the subtransaction Ti to Sitei and the participant reporting to the coordinator the successful execution of the work with a yes message. 2. The second compulsory round of messages involves the coordinator asking the participant to commit and the participant acknowledging it. Let the number of times the Repeat...Until loop is executed, be R. Each time this loop is executed, there is one round of message flow between the coordinator and each low reading participant, a total of two messages across the network. Thus, the number of messages exchanged between coordinator and participants due to the SignalStatus command is 2  R  nlow . On top of this, we have the 4  nlow compulsory messages; these are the messages in the first round when the subtransactions are distributed along with the vote requests and the messages in the very last round when the commit decision is sent to participants. Thus, the total number of messages between the coordinator and the low reading participants is 4  nlow ‡ 2  R  nlow . Between the coordinator and the nonlow reading participants, there are 4  nsame messages. Thus, for ASEP the number of messages across the network is:

898

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING,

Number of messages ˆ 4  nsame ‡ 4  nlow ‡ 2  R  nlow ˆ 4  n ‡ 2  R  nlow ;

[2]

where n ˆ nsame ‡ nlow . The number of messages in ASEP expressed as a fraction of the messages exchanged in EP is thus:

[3]

ASEP 4  n ‡ 2  R  nlow ˆ EP 4n R  nlow : ˆ1‡ 2n

…1†

An important observation is that the overhead for message exchanges is linear in R and is negligible if nlow  n. That is, if the number of low reading subtransactions is much smaller than the number of transactions for a particular distributed transaction, then the overhead for message exchanges in ASEP is almost the same as that in EP.

9

CONCLUSIONS

This paper presents an advanced secure commit protocol (ASEP) for MLS distributed database systems. ASEP improves upon the secure early prepare protocol (SEP) of [1] by allowing the distributed transaction to proceed even when a subtransaction has released its low-level read locks prematurely. ASEP allows partial rollback of subtransactions so that the distributed transaction can proceed to completion without sacrificing consistency. ASEP also allows forward recovery measures to be incorporated, which will prevent starvation if required, albeit at the expense of consistency. As part of our future work, we would like to implement ASEP using a transaction processing language like Avalon [3]. This will enable us to analyze not only its performance, but its impact on different types of transaction processing, particularly long lived transactions in a cooperative environment, as well.

ACKNOWLEDGMENTS The work of S. Jajodia was partially supported by the US National Science Foundation under grants IRI-9303416, IRI9633541, and INT-9412507, and by US National Security Agency under grants MDA904-96-1-0103 and MDA904-961-0104. The work of L. Mancini was partially supported by the Italian M.U.R.S.T. The work of I. Ray was partially supported by US National Science Foundation under grant IRI-9303416. A preliminary version of this paper under the title ªAn Advanced Commit Protocol for MLS Distributed Database Systems,º appeared in the Proceedings of the Third ACM Conference on Computer and Communications Security, New Delhi, India, pp. 119±128.

REFERENCES [1]

V. Atluri, E. Bertino, and S. Jajodia, ªDegrees of Isolation, Concurrency Control Protocols, and Commit Protocols,º Database Security, VIII: Status and Prospects, J. Biskup et al., eds., pp. 259± 274, 1994.

[4] [5]

[6] [7] [8] [9]

[10]

[11]

[12] [13] [14] [15]

VOL. 12,

NO. 6,

NOVEMBER/DECEMBER 2000

P.A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems. Reading, Mass.: AddisonWesley Publishing, 1987. J.L. Eppinger, L.B. Mummert, and A.Z. Spector, Camelot and Avalon: A Distributed Transaction Facility. San Mateo, Calif.: Morgan Kaufman, 1991. T.H. Hinke and M. Schaefer, ªSecure Database Management System,º Technical Report RADC-TR-75-266, System Development Corp., Nov. 1975. J.D. Horton, R.H. Cooper, W.F. Hyslop, B.G. Nickerson, O.K. Ward, R. Harland, E. Ashby, and W.M. Stewart, ªThe Cascade Vulnerability Problem,º J. Computer Security, vol. 2, no. 4, pp. 279± 290, 1993. Informix-OnLine/Secure Administrator's Guide. Menlo Park, Calif.: Informix Software, Inc., Apr. 1993. Informix-OnLine/Secure Security Features User's Guide. Menlo Park, Calif.: Informix Software, Inc., Apr. 1993. S. Jajodia and B. Kogan, ªTransaction Processing in Multilevel Secure Databases Using Replicated Architecture,º Proc. IEEE Symp. Research in Security and Privacy, pp. 360±368, May 1990. S. Jajodia and C. McCollum, ªUsing Two-Phase Commit for Crash Recovery in Federated Multilevel Secure Database Management Systems,º Dependable Computing and Fault-Tolerant Systems, C.E. Landwehr et al., eds., vol. 8, pp. 365±381, 1993. S. Jajodia, C.D. McCollum, and B.T. Blaustein, ªIntegrating Concurrency Control and Commit Algorithms in Distributed Multilevel Secure Databases,º Database Security, VII: Status and Prospects, T.F. Keefe and C.E. Landwehr, eds., pp. 109±121, 1994. J. McDermott and S. Jajodia, ªOrange Locking: Channel-Free Database Concurrency Control via Locking,º Database Security, VI: Status and Prospects, B.M. Thuraisingham and C.E. Landwehr, eds., pp. 267±284, 1993. J.K. Millen and M.W. Schwartz, ªThe Cascading Problem for Interconnected Networks,º Proc. Fourth Aerospace Computer Security Applications Conf., pp. 269±274, Dec. 1988. C. Mohan, B. Lindsay, and R. Obermarck, ªTransaction Management in R* Distributed Database Management System,º ACM Trans. Database Systems, vol. 11, no. 4, pp. 378±396, Dec. 1986. J. Eliot and B. Moss, Nested Transactions. An Approach to Reliable Distributed Computing. Information Systems Series. Cambridge, Mass.: MIT Press, 1985. J.W. Stamos and F. Cristian, ªCoordinator Log Transaction Execution Protocol,º Distributed and Parallel Databases, vol. 1, pp. 383±408, 1993.

Indrajit Ray received the PhD degree in information technology from George Mason University in Fairfax, Virginia in 1997. He is an assistant professor in the Computer and Information Science Department at the University of Michigan, Dearborn. Dr. Ray's research interests include transaction models and architectures, security of transaction processing systems, electronic commerce protocols, data warehousing, and data mining. Dr. Ray's papers have been published in, among others, the IEEE Transactions on Knowledge and Data Engineering and Distributed and Parallel Database, An International Journal, as well as the ACM Conference on Computer and Communications Security. Luigi V. Mancini received the Laurea degree in computer science from the University of Pisa, Italy, in 1983 and the PhD degre in computer science from the University of Newcastle in Tyne, UK, in 1989. From 1989 to 1992, he was an assistant professor in the Dipartimento di Informatica at the University of Pisa, Italy. From 1992 to 1996, he was an associate professor in the Dipartimento di Informatica e Scienze dell'Informazione at the University of Genova, Italy. Since 1996, he has been an associate professor in the Dipartimento di Scienze dell'Informazione of the University of Roma "La Sapienza". His current research interests include distributed algorithms and systems, computer and information security, and transaction processing systems.

RAY ET AL.: ASEP: A SECURE AND FLEXIBLE COMMIT PROTOCOL FOR MLS DISTRIBUTED DATABASE SYSTEMS

Sushil Jajodia received the PhD degree from the University of Oregon, Eugene. He is BDM chair professor and chairman of the Department of Information and Software Engineering and director of the Center for Secure Information Systems at the George Mason University, Fairfax, Virginia. He joined GMU after serving as the director of the Database and Expert Systems Program within the Division of Information, Robotics, and Intelligent Systems at the National Science Foundation. Before that, he was the head of the Database and Distributed Systems Section in the Computer Science and Systems Branch at the Naval Research Laboratory, Washington, and an associate professor of computer science and director of graduate studies at the University of Missouri, Columbia. He has also been a visiting professor at the University of Milan, Italy, and at the Isaac Newton Institute for Mathematical Sciences, Cambridge University, England. His research interests include information security, temporal databases, and replicated databases. He has authored three books, including Time Granularities in Databases, Data Mining and Temporal Reasoning (Springer-Verlag, 2000), Information Hiding: Steganography, and WatermarkingÐAttacks and Countermeasures (Kluwer, 2000), edited 16 books, and published more than 200 technical papers in the refereed journals and conference proceedings. He received the 1996 Kristian Beckman award from IFIP TC 11 for his contributions to the discipline of information security, and the 2000 Outstanding Research Faculty Award from GMU's School of Information Technology and Engineering. Dr. Jajodia has served in different capacities for various journals and conferences. He is the founding editor-in-chief of the Journal of Computer Security. He is on the editorial boards of IEEE Concurrency, ACM Transactions on Information and Systems Security, and International Journal of Cooperative Information Systems. He serves as the program chair of the 2000 ACM Conference on Computer and Communications Security (CCS'00) and 2001 International Conference on Conceptual Modeling (ER2001). He is a senior member of the IEEE and has been named a Golden Core member for his service to the IEEE Computer Society. He is a past chairman of the IEEE Computer Society Technical Committee on Data Engineering and the Magazine Advisory Committee. He is a senior member of the IEEE and a member of IEEE Computer Society and Association for Computing Machinery. The URL for his web page is http://isse.gmu.edu/~csis/ faculty/jajodia.html.

899

Elisa Bertino received the Laurea degree in computer science from the University of Pisa, Italy, in 1980. Currently, she is a professor of database systems in the Department of Computer Science at the University of Milan where she heads the Database System Group. Since October 1997, she has also been the chair of the Computer Science School of the University of Milano. She has also been on the faculty in the Department of Computer and Information Science at the University of Genova, Italy. Until 1990, she was a researcher for the Italian National Research Council in Pisa, Italy, where she headed the Object-Oriented Systems Group. She has been a visiting researcher at the IBM Research Laboratory (now Almaden) in San Jose, at the Microelectronics and Computer Technology Corporation in Austin, Texas, at George Mason University in Fairfax, Virginia, and at Rutgers University in Newark, New Jersey. She is a member of the IEEE.