Self Improvement

A security punctuation framework for enforcing access control on streaming data

Abstract The management of privacy and security in the context of data stream management systems (DSMS) remains largely an unaddressed problem to date. Unlike in traditional DBMSs where access control policies are persistently stored on the server
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A Security Punctuation Framework for EnforcingAccess Control on Streaming Data Rimma V. Nehme #1 , Elke A. Rundensteinerr ∗ 2 , Elisa Bertino #3 #  Department of Computer Science and CERIAS, Purdue UniversityW. Lafayette, IN 47906 USA 1 3 ∗  Department of Computer Science, Worcester Polytechnic InstituteWorcester, MA 01609 USA 2  Abstract —The management of privacy and security in thecontext of data stream management systems (DSMS) remainslargely an unaddressed problem to date. Unlike in traditionalDBMSs where access control policies are persistently stored onthe server and tend to remain stable, in streaming applications thecontexts and with them the access control policies on the real-timedata may rapidly change. A person entering a casino may want toimmediately block others from knowing his current whereabouts.We thus propose a novel “stream-centric” approach, wheresecurity restrictions are not persistently stored on the DSMSserver, but rather streamed together with the data. Here, theaccess control policies are expressed via security constraints(called security punctuations , or short, sps ) and are embedded intodata streams. The advantages of the sp model include flexibility,dynamicity and speed of enforcement. DSMSs can adapt to notonly data-related but also security-related selectivities, whichhelps reduce the waste of resources, when few subjects haveaccess to data. We propose a security-aware query algebra andnew equivalence rules together with cost estimations to guide thesecurity-aware query plan optimization. We have implementedthe sp framework in a real DSMS. Our experimental results showthe validity and the performance advantages of our sp model ascompared to alternative access control enforcement solutions forDSMSs. I. I NTRODUCTION  A. Security in Data Streaming Environments The need for people to protect themselves and their assetsis as old as humankind. The increasing use of electronic,sensor and GPS devices means that individuals today havean ever-growing range of electronic (data) assets that maypotentially be at risk. When computing devices are integratedwith people, various personal information is expressed indigital form. Devices can communicate this information overnetworks and users have no control over who and for whatpurpose may query their data. Some users, knowing that theirpersonal information (e.g., location, health condition) is notsafeguarded, may hesitate to use such devices because of therisk of data being misused.Traditional access control schemes which typically assumefinite persistent datasets and static (or rarely changing) accesscontrol policies become largely inapplicable in this new streamparadigm. This inapplicability is due to the fact that streamenvironments tend to be highly dynamic. Data is continuouslygenerated and may have different security sensitivities depend-ing on the context, on personal preferences or on the streamingvalues – all of which may frequently change at a possibly veryfine granularity.  B. Motivating Examples Example 1: Protection against context-aware spam. Peoplemay want to block unwanted businesses from sending themadvertisements based on their location or any other informa-tion. As a person is driving or walking, the device may adaptsecurity constraints based on the proximity of the businessesand his/her preferences limiting to who would be allowed to“see” the person. This helps to impede focused marketingefforts and to avoid receiving “context-aware spam” – servicesor information people don’t know of or agree to. Example 2: Privacy protection of personal health data. Apatient may be living at home with a health monitoring deviceattached to him which can detect early health abnormalitiesand transmit alert signals to relevant personnel. However, thepatient may prefer only certain users, such as only his doctoror a nurse, to have access to his streaming data and preventaccess for any third-parties (e.g., insurance companies or otherhospitals). Only if his vital signs go far above the norm andhe is in an imminent danger needing urgent care, should theclosest hospital or ER gain access to his streaming data.We envision that individual devices transmitting streamingdata will be able to inject their respective security restrictionstogether with the data. The policies, as will be illustrated,can be encoded into a compact format, and in most casescan be included into the same network message with thedata. Thus little demand for additional network communicationis expected. In this paper, we assume that streaming datais transmitted securely from a data source to the streamingdatabase. That is, the possibility of the data being interceptedand compromised on the network is beyond the scope of thispaper. C. Alternative Access Control Mechanisms To motivate our approach, we sketch and compare alternatemethods to enforce access control on streaming data.   Non-streaming: Store-and-probe approach . The policies onthe streaming data are collected in one place and stored in apersistent table. Whenever an access to the data is requested,the policy table is probed, to see if the access should begranted or denied. The advantage of this approach is itssimplicity. All policies are stored and updated in one place.The main disadvantage is its inability to cope with frequentpolicies’ changes. Every change in a policy would requirean update to the policy table, and every request to a datawould require a lookup to this central place. Large numberof data sources, fine-granularity of policies, frequent policychanges and continuous lookups may create a bottleneck inthe performance of a streaming system. Streaming: Tuple-embedded approach . An alternative mech-anism is to stream security restrictions embedded inside datatuples. This approach is similar to other works in the literature,where extra tuple fields are added for meta-data, e.g., tuplelineage in Eddies [1]. Different attributes in a tuple, however,may each have a distinct policy, which may lead to anexplosion in tuple sizes, potentially seriously impacting thesystem performance. Moreover, tuples that arrive adjacent toeach other in the stream are quite likely to be generatedbased on the same context (e.g., location, time), and thusmay frequently have similar access control policies. Using thisapproach, tuples with identical policies would still carry theirown (redundant) copy, and the query processor would stillhave to process every tuple individually to guarantee that nounauthorized access is granted.One possible improvement to minimize per tuple storageoverhead could be to encode policies as bitmaps , and thenabstract policy-based filtering using bitmap operations (assuggested for query processing status in Eddies [2]). A bitmaprepresentation is highly compressable, so the storage overheadwould be somewhat minimized. However, even with compres-sion, still this approach suffers from redundant storage andunnecessary per-tuple processing overhead. Streaming: Punctuation-based approach . The third alterna-tive, which we adopt in our work, is a punctuation-basedapproach, where security meta-data tuples are interleaved withthe data tuples in the streams. Punctuation-based solutionhas several advantages over the above-mentioned approaches.First, the access control is dynamic and the speed of en-forcement is fast, because security restrictions are streamedtogether with the data. Second, the security punctuations maybe shared by multiple tuples that have similar policies. Thusno redundant copies of policies are stored, memory overheadis minimized and the security-related processing is shared.Policies in security punctuations can also be encoded in abitmap format for compactness, thus further reducing security-related processing. For ease of readability, in the rest of thepaper we present security punctuations in the alphanumericformat. spsp Data TuplesSecurity Punctuations...Q 1 Q n Q n-1 Q 2 ...Data Providers SP Analyzer spspsp Data Stream ManagementSystem (DSMS) QueryResults Fig. 1. System architecture.  D. Our Proposed Solution: SP Framework  We propose to stream security constraints called security punctuations (or short sp s) 1 , interleaved with the actual streamdata describing an access control policy on the upcomingportion of the stream. An sp is a predicate that informs thestream processor of  who has access when to which streamingdata. A conceptual view of a stream with security punctuationsis shown in Figure 1.Data sources emit sp s based on the user specifications. Inour work, we distinguish between two types of users: (1) usersproviding the streaming data, termed data providers (short  DP s), and (2) users querying the streaming data, termed queryspecifiers (short QS  s). When query specifiers register contin-uous queries for execution, each query inherits the securityrestriction(s) associated with the query specifier registered toreceive the results. When the stream data arrives to the server,the database engine examines the streaming data tuples’ policystored in the sp s and checks if the queries conform to thepolicy, discarding the data that no query has access rights to.We would like to emphasize that we do not define a newaccess control model in this paper, such as RBAC [3] orMAC [4]. Instead, we propose an access control enforcementmechanism suitable for streaming data and investigate itsinteraction with query processing and optimization. As in mostreal environments [4], [3], we assume that data providers andusers querying the data use the same access control model.  E. Our Contributions • We introduce a novel sp model that supports declarativeaccess control specification and enforcement on real-timestreaming data. • We propose a “security-aware” stream algebra, by en-hancing the traditional algebra with security-aware ex-tensions and new algebraic equivalence rules. • We present a pipelined execution model enabled by thesecurity-aware algebra and describe security-aware queryoptimization employing the new algebraic rules and costestimations in query plan rewriting. • Our experimental analysis on a real DSMS CAPE  [5]shows that sp framework is superior to alternative accesscontrol mechanisms for streaming data in terms of bothprocessing and memory.The rest of the paper is organized as follows: We introduceour framework and describe our assumptions in Section 2.Section 3 presents the concept of security punctuations. In 1 We chose the name “ security punctuations ”, because by introducing sp s into datastreams, we subdivide i.e., punctuate infinite data streams into finite partitions withassociated access control policies.  Section 4 we discuss the techniques for query processing andoptimization with embedded into streams sp s. Physical imple-mentation and query optimization are presented in Sections5 and 6. Our experimental evaluation of the sp framework ispresented in Section 7. Section 8 reviews related work, andSection 9 concludes the paper.II. P RELIMINARIES  A. Subjects, Objects and Rights The subject, object and right concepts are well knownin access control [4]. An object  is an entity that containsinformation. Access to an object implies the right to usethe information it contains. Examples of objects in streamingsystems are: streams, tuples, and tuple attributes. A subject  may invoke a request to access an object, e.g., a request to readdata. The subjects in our model are a set of users who specifycontinuous queries in the DSMS. We use flat  role-based accesscontrol (RBAC) model [3] as an example, as it is one of themost widely used access control models, and show how it canbe implemented using sp s. However, our framework is generaland any other access control model, e.g., DAC, MAC [4], etc.,can be implemented using sp s.Query specifiers, i.e., subjects, activate their roles when theysign into DSMS. We require that each query specifier belongsto at least one role. This assignment cannot be changed whilehe/she is registered to receive the results of any of the currentlyexecuting queries. Subjects acquire rights which are the setof privileges that they can hold and execute on an object.In this work, we consider a read right only. Just about allstream systems are read-only right now. Hence this is a naturalfocus. Our model could be extended to support other rights aswell, such as update, delete, etc. An access control policy corresponds to a set of rules indicating which objects thesubjects are allowed to access. Authorization is the grantingof such rights.  B. Streaming Model We consider a centralized DSMS processing long-runningqueries on a set of data streams. A continuous data stream s is a potentially unbounded sequence of tuples that arrive overtime. Tuples in the stream are of the form t  = [ sid  , tid  , A , ts ],where sid  is the stream identifier, tid  is the tuple identifier 2 , A is a set of attribute values, and ts is the timestamp of the tuple.As commonly assumed in other streaming systems [6], [7], thetimestamps of the stream elements are ordered. Similarly, sp salso arrive in order [8]. The out-of-order sp arrival can behandled similarly to prior works [8], [9].We consider a set of continuous queries { q  1 , ...q   p } execut-ing over the data streams. Each query q  i has an associatedset of roles of the subjects registered to receive the results of that query. Queries are represented by query plans composedof operators op 1 , ... , op k , where each operator inherits theroles associated with the queries for which it processes the 2 This may be similar to a primary key in relational tables, or it may be a unique setof attributes used to identify a particular data provider, e.g., a patient id  . sp-batch s-punctuated segment  sp 1 sp 2 sp 3 tuple a tuple b tuple c sp 4 tuple b …… time Fig. 2. Applicability of sec. punctuations. data. Operators may be shared, hence an operator may acquireaccess rights from multiple queries.A DSMS server has a security punctuation analyzer  compo-nent (Figure 1) which serves two purposes: (1) to combine thesecurity punctuations with similar policies to reduce memoryand processing overhead, and (2) to allow server-side spec-ification of additional policies. In the latter case, the serverpolicies are translated into the format of security punctuationsand combined with the arriving data provider sp s. This designallows organizations to enforce their own policies in additionto the ones specified by the data providers. For example, ahospital may add its own policies in addition to the policiesspecified by a patient on her streaming health data. We assumethat server-specified policies may not  override, but may further“refine” the data provider policies by putting-in additionalconstraints.III. S ECURITY P UNCTUATIONS (SP S )  A. Applicability of SPsSecurity punctuations ( sp s) are meta-data introduced into adata stream to specify who has access rights when to which streaming data. Sp s always precede the tuples for which theydescribe the access control policy (Figure 2). A policy mayapply to: a (sub)stream, a tuple, or an attribute of a tuple.Generally, we refer to them as objects . The tuples betweentwo consecutive punctuations form an s-punctuated segment  which defines the applicability scope of the preceding sp .Policies may be expressed by one or more sp s and mayapply to zero or more tuples. A set of consecutive sp s areassumed to belong to the same sp-batch and are interpretedas a single access control policy. All sp s of the same policyhave the same timestamp ts – the time when the policy goesinto effect. A policy P j applicable to an object o at a time ts j overrides an earlier policy P i ( ts i < ts j ) which was applicableto o . Tuples are completely unaware of  sp s in the stream. If there is no sp authorizing access to an object, denial-by-default  is enforced; any request to access that object will be denied.  B. Security Punctuation Structure Figure 3 illustrates a security punctuation structure. The  Data Description Part  (  DDP ) specifies which object(s) theaccess control policy applies to. The Security Restriction Part  ( SRP ) denotes both the access control model type and thesubjects authorized by the policy. Since we use role-basedaccess control in this work, the SRP part of  sp s specifies RBACas the model type and a set of  role (s) that are authorized bythe sp 3 . The Sign specifies if the authorization is positive or negative [10]. Finally, the Immutable field indicates if the sp can be combined with other (e.g., server-specified) policies.Policies can be specified at the granularity of a stream, a 3 We omit the access control model specification in the sp s in the rest of the paper,since all sp s are assumed to use RBAC model.  Data DescriptionPart ( DDP )Security RestrictionPart ( SRP )Stream(s), Tuple(s),Attribute(s) ... Sign +- Immutable TF Access ControlModel Type & ValueTimestamp ts Fig. 3. Security punctuation structure. tuple, or an attribute. Since many objects may share similarpolicies, we use regular expressions to describe objects andtheir policies inside sp s. Regular expressions facilitate compactpolicy representation.We now formally define security punctuations. Let eval(N,e) be a function that, given a set of values N  and a regularexpression e , returns a subset N  e ⊆ N  that matches e . Let S  = { s 1 ,... s m } be the set of all streams, let T  = { t  i, 1 ,... t  i,n } bethe set of all possible tuple identifiers in a stream s i ∈ S  , let  A = { a i,j, 1 ,... a i,j,k } be the set of attributes in a tuple t  i,j ∈ T  and let R = { r  1 ,... r  l } be the set of all roles in the system. Let e s , e t , e a , and e r denote regular expressions specified against S  , T  , A and R , respectively. Let O = { o s  ,o t  ,o a } be the setof objects, where o s =( ¯ s ), o t =( ¯ s , ¯ t ), and o a =( ¯ s , ¯ t , ¯ a ), such that ¯ s ∈ eval(S,e s ) , ¯ t ∈ eval(T,e t ) and ¯ a ∈ eval(A,e a ) . A securitypunctuation is then defined as follows.  Definition 3.1: A security punctuation sp is meta-data em-bedded into a stream that defines an access control policy P  on a setof objects O and has the following form: < DDP | SRP | Sign | Immutable | ts > where sp.  DDP = ( e s ,e t ,e a ), sp. SRP = e r and ts is the timestamp of the policy P  . The semantics of the sp is the following: • if Sign = ‘+’: a subject with role ¯ r ∈ eval(R,e r ) may access anyobject o ∈ O at any time ts access ≥ sp.ts . • if Sign = ‘-’: a subject with role ¯ r ∈ eval(R,e r ) is denied accessto any object o ∈ O at any time ts access ≥ sp.ts . If the field Immutable = false , the security punctuation may becombined with the server-specified policies applicable to thesame objects. Otherwise, the sp is immutable, and the server-side policies are ignored 4 . C. Security Punctuation Examples Consider three data streams (Figure 4): HeartRate , Body-Temperature and BreathingRate and the set of roles R = { C,D,DM,E,GP,ND } . The following sp s may be specified inthese streams: • Stream level policy : <s 1 , *, * | C  | + > Only queries registered by a cardiologist ( C  ) can querythe stream HeartRate ( s 1 ). • Tuple level policy : < *, [120,133], * | GP | + > Only queries registered by a general physician (GP) canaccess data tuples (from any data stream) of patients withids between 120 and 133. • Attribute level policy : < { s 1 ,s 2 } , *, { Temperature , Beats per min } | {  D , ND } | + > Only a doctor ( D ) or a nurse-on-duty ( ND ) can querythe temperature and the heart beat from streams s 1 , s 2 . 4 For simplicity of presentation, we assume positive and mutable sp s in the rest of ourdiscussion. We omit the Immutable field. Unless noted otherwise, all sp s are assumed tobe mutable. Patient_id | Beats_per_min | Timestamp 120 | 70 | Sep-12-05 9:17:00 s  1   Patient_id | Temperature | Timestamp 120 | 98.6 | Sep-12-05 9:21:00 s  2  Patient_id | Frequency | Depth | Timestamp 120 | 8 | 38 | Sep-12-05 9:22:00 s  3  .........Hospital Employee (E)Nurse-on-Duty (ND)Doctor (D)Cardiologist (C)Dermatologist (DM)GeneralPhysician (GP) HeartRate Stream BodyTemperature Stream BreathingRate Stream  (a) Sample Data Streams(b) Sample Roles Fig. 4. Example of a stream environment.  D. CQL Extensions to Support SPs We have extended the Continuous Query Language (CQL)[11] to support the specification of security punctuations. Sincethe roles of queries are inferred from the subjects specifyingthe queries, the CQL query syntax has been left unchanged.The proposed sp declaration syntax is: INSERT SP [[AS] sp name  ] INTO STREAM [ stream name  | stream id  ] LET [ sp name. ] DDP = < ddp expr  > ,[ sp name. ] SRP = < srp expr  > ,[[ sp name. ] SIGN = { positive  | negative  } ,][[ sp name. ] IMMUTABLE = { true  | false  } ]  E. Preserving Correct Security Semantics For manipulating sp s on the server, the following fouroperations are used: match() , union() , intersect() and over-ride() . match() identifies which tuples are related to an sp based on the regular expressions in sp.DDP . union() performsthe union and intersect() the intersection of the policies,respectively. With intersection semantics, the access to thedata decreases as additional sp s are applied. Conversely, withunion semantics, access to data increases as additional sp s areapplied. override() replaces a policy with a new policy.When multiple sp s are applicable to the same tuples, thefollowing three design choices are used to preserve the correctsecurity semantics. union() is used when multiple sp s arrivefrom the same data provider and the sp s have the sametimestamp. Here the sp s represent a single policy and thus areunion-ed together. intersect() is used when combining the dataprovider and the server-specified sp s. This is done to disallowthe server policies from increasing the access on the data.Alternatively, a data provider can also set the Immutable fieldof the sp s to true, thus preventing any modification to his/herpolicies on the server side. override() is used when multiple sp s arrive from the same data provider and the sp s havedifferent timestamps. The sp with the more recent timestampoverrides any earlier sp s applicable to the same object(s).IV. S ECURITY -A WARE Q UERY P ROCESSING  A. Alternative Approaches With security punctuations embedded in data streams, queryresults may be produced as follows:  Pre-filtering . Each query may have its own access control filterinstalled, which pre-filters arriving tuples based on the accessrights of the query in advance, before entering the query plan.This pre-filtering discards the sp s, since the streams wouldonly contain tuples that the query is authorized to access.Thus, query plans can simply consist of traditional query  Q  1 s  2  s  3  s  4  s  1 Q  2  Q  3  - shared subplan- SS operator SSSSSSSSSSSS Fig. 5. Security-enhanced query plan. operators. This approach, however, forces each query to beexecuted separately, even if queries share subexpressions buthave different access rights. Fixed placement of the accesscontrol filtering to always be at the beginning of the plan mayalso add a significant cost compared to if it were to be donelater.  Post-filtering . In reverse, queries can be executed first, andthe results then get filtered postmortem based on the accessrights of the queries. This approach is advantageous whenthe selectivity of the query operators is high and the accessrights are loose. Using post-filtering, query execution can beshared just as in regular query processing. But again, theaccess control filtering being fixed (this time at the end of thequery plan) may introduce unnecessary processing overhead insome circumstances. A lot of work may be done by expensiveoperators, only for the results to be discarded later because of access rights limitations.  Intermediate filtering . The pre- and post- filtering approachesin many cases can be prohibitively expensive. Thus, it may bebeneficial to make the placement of security predicates in themiddle of the query plan. Such interleaving may significantlyreduce the cardinality of intermediate results. To make accesscontrol filtering flexible, we isolate this functionality intoa special-purpose operator that can be placed anywhere inthe query plan. The goal of this operator is to discard datatuples that a query has no access rights to . This filteringis based on the roles associated with the queries and thetuples’ policies represented by the streaming sp s. We introducea novel Security Shield  ( SS  ) operator for this purpose. Inaddition to flexible placement, SS  operators facilitate efficientsharing of query plans. Figure 5 illustrates an example of ashared query plan for three queries, Q 1 , Q 2 , and Q 3 withembedded SS  operators.  B. Security-Aware Query Algebra To enable security-aware query processing and optimization,we extend stream algebra [12] to become security-aware. TableI summarizes the definitions of the operators in the algebra 5 . “Security Shield”  ( ψ ) is a new operator designed to supportaccess control filtering based on streaming sp s and the securitypredicates defined by the queries’ access rights. SS  checks thestreaming sp s, and if an access control policy does not satisfythe predicate of  SS  , the tuples and their sp s are discarded, thuspreventing unauthorized access. SS  operator can be viewed asa “select operator” that filters tuples based on the streamingmetadata, i.e., sp s. 5 To keep the presentation concise, we do not describe security-aware set operationsin this paper. TABLE IS ECURITY - AWARE ALGEBRA . Notation: Let • t ∈ T  be a tuple in a data stream T  • P  t be the access control policy of the tuple t represented by sps • p be a security predicate – a set of roles associated with a query Security Shield (SS) : ψ , with security predicate p • ( t , P  t ) ∈ ψ p ( T  ) iff  P  t ∩  p  = ∅  Projection : π , with an attribute a i • ( t , P  t ) ∈ π a 1 ( T  ) iff  t consists of  a i and P  t  = ∅ Selection : σ , with a condition c • ( t , P  t ) ∈ σ c ( T  ) iff  t satisfies c and P  t  = ∅  Join :  , with a join condition c • ( t , P  t ) ∈ T  c E  iff  t ∈ T  × E  and satisfies c and P  T t ∩ P  Et  = ∅ where P  T t and P  Et are the policies of the base tuples from T  and E   Duplicate Elimination : δ • ( t , P  t ) ∈ δ ( T  ∗ ) iff  t ∈ T  , T  ∗ ⊆ T  , P  t  = ∅ and t  / ∈ T  ∗ such that t = t  Group-by : G aggA , with agg aggregate function and attribute A • ( t , P  t ) ∈ G aggA ( T  ) iff  t ∈ T  , A ∈ t and P  t  = ∅  Projection ( π ) is an unary operator that processes newtuples by on-the-fly discarding unwanted attributes. This op-erator simply propagates the streaming sp s and thereafter theprojected tuples. If an sp describes a policy for only theprojected attributes, the sp is discarded by the project operatorfrom the stream as well. Selection ( σ ) is a unary operator that drops tuples that donot satisfy the query selection condition. A select operator“delays” sp propagation until at least one of the tuples withthe policy described by the sp satisfies the select condition.Otherwise if all tuples with the same policy are filtered, their sp (s) are discarded as well.  Join (  ) is a binary operator that joins the tuples of itsinput streams. The following modifications are made to the join operator to make it sp -aware: (1) the policies representedby sp s are stored together with tuples in the stream window,(2) if a tuple joins with another tuple, the policies of thebase tuples are intersected. If the intersection is empty, the join results are discarded, because the base tuples’ policiesare incompatible. Otherwise, the results are sent to the outputstream, preceded by the sp (s) depicting the intersection of thebase policies.  Duplicate elimination ( δ  ) over a sliding window stores bothits input and its current output tuples, and at all times theoutput contains exactly one tuple with each distinct value v present in the input. The policies represented by sp s are storedtogether with the tuples in the output state. When a new tuplewith a duplicate value arrives, its policy is intersected withthe policy of the tuple in the output state. Let P  old be thepolicy of the tuple with value v in the output state and let P  new be the policy of the new tuple with the same value v .There are 3 cases to consider: (1) P  old ∩ P  new = ∅ . If thepolicy intersection is empty, the previously outputted resultwas not accessible by the queries that may access the newtuple with value v . Thus, we send v to the output stream,preceded by sp (s) describing the policy P  new . We also store P  new in the output state. (2) P  old ∩ P  new = P  new . If the policyintersection is not empty and equals P  new , we do not sendanything to the output stream, because previously outputtedtuple was accessible. (3) P  old ∩ P  new  = P  new and P  old ∩ P  new  = ∅ . If the policy intersection is not empty and it is
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks