Martin Kolar
email: kolar@lcc.uma.es

Carmen Fernandez-Gago

Javier Lopez

Policy Languages and Their Suitability for Trust Negotiation

Entities, such as people, companies, institutions, authorities and web sites live and exist in a conjoined world. In order to live and enjoy social benefits, entities need to share knowledge, resources and to cooperate together. The cooperation brings with it many new challenges and problems, among which one is the problem of trust. This area is also important for the Computer Science. When unfamiliar entities wish to cooperate, they do not know what to expect nor whether they can trust each other. Trust negotiation solves this problem by sequential exchanging credentials between entities, which have decided to establish a trust relationship in order to reach a common goal. Entities specify their own policies that handle a disclosure of confidential information to maintain their security and privacy. Policies are defined by means of a policy language. This paper aims to identify the most suitable policy language for trust negotiation. To do so, policy languages are analysed against a set of criteria for trust negotiation that are first established.

Introduction

Entities in our world, in order to live and enjoy the benefits of our civilisation, need to cooperate together and share many resources, such as knowledge, services, products and jobs. This sharing or exchanging requires fair conditions for all parties, so that everybody can use shared resources equally and receive fair consideration for each contribution. One of the biggest issues is trust. Entities need to know who they can trust when cooperating, to prevent deception and abuse. They need to be sure the others are going to behave as expected [START_REF] Gambetta | Can We Trust Trust[END_REF]. Trust is usually built up over a long period of time, as entities get to know each other better. In this case, the main constructor of trust is experience, which is gained with each interaction and if the output is positive, trust increases. This way trust is built step by step. An entity supposes that others generally do not change too much over time, so its previous experience with them is also relevant for the future. An entity expects others to provide similar outputs in the future, as they have provided in the past. This expectation, positive or negative, is de facto trust.

However, trust cannot always be established in this natural way. Nowadays with online environments, our communication capabilities have been widely extended and the number of participating entities is enormous. Because there are so many of them, their anonymity tend to increase. However, entities still need to be sure about the provision of their resources, information, etc. to other parties [START_REF] Jøsang | A Survey of Trust and Reputation Systems for Online Service Provision[END_REF]. For this reason suitable approaches for establishing trust and maintaining confidence should be used. Trust negotiation establishes trust without the need of a direct previous experience with an entity. It is a credentials exchange process between two entities resulting in the establishment of trust [START_REF] Winsborough | Automated Trust Negotiation[END_REF][START_REF] Winsborough | Towards Practical Automated Trust Negotiation[END_REF], where entities authenticate themselves by disclosing their private information. This information may be signed by an authority assuring their genuineness and authenticity. Generally, entities involved in trust negotiations need to control access over their data. This can be achieved by a definition of policies in a policy language. Policy languages provide a suitable way to express various types of policies and cover by them diverse aspects of trust negotiation, such as security and privacy. During trust negotiation, policies are read and evaluated in order to make credential disclosure decisions.

For the purpose of this paper, policy languages are observed for their suitability of usage for trust negotiation. This requires analysing the trust negotiation criteria that comprise a set of requirements needed to efficiently handle trust negotiation. The policy languages are analysed by classifying their attributes. Then, the attributes are checked against the identified criteria and if a match is found, the language is marked as supporting the criterion. The more criteria the policy language supports, the more suitable it is. Some criteria may be more important than others and some may even be essential. As a result, one or more policy languages suitable for trust negotiation can be identified. This paper identifies the general criteria for trust negotiation and analyses and classifies policy languages according to the selected criteria. It is important to carefully select the possibly suitable languages for trust negotiation that are to be classified. This classification is helpful to make a decision, which policy language should be chosen for a trust negotiation model. An engineer designing such model can view attributes of the analysed languages and thus select the most suitable language according to his needs.

The remainder of this paper is organised as follows: In Section 2, related work on trust, trust negotiation, policy languages and their classification is presented. Section 3 describes and explains the general concepts of trust negotiation and Section 4 identifies and presents the trust negotiation criteria. In Section 5, policy languages are analysed and matched against the criteria identified in Section 4. Finally, Section 6 concludes the paper and outlines future work.

Related Work

Entities experience trust on an everyday basis as they relate to each other and make decisions. Gambetta [START_REF] Gambetta | Can We Trust Trust[END_REF] defines trust as a subjective probability, by which an individual A expects another individual B to perform a given action, on which its welfare depends. This definition supposes that the trustor is dependent on the trustee and the trustee is reliable. According to Jøsang [START_REF] Jøsang | A Survey of Trust and Reputation Systems for Online Service Provision[END_REF], there are two common definitions of trust called reliability trust and decision trust. Reliability trust can be interpreted as the reliability of something or somebody and decision trust as a magnitude of willingness of one entity to be dependent on another in a given scenario. The entity should feel relatively secure and comfortable about the other, even though it must accept possible negative consequences. Grandison and Sloman [START_REF] Grandison | A Survey of Trust in Internet Applications[END_REF] define trust related to a given context: "Trust is the firm belief in the competence of an entity to act dependably, securely, and reliably within a specified context." From these definitions it is clear that the area of trust is quite diverse and it is difficult to define a single, standard and general trust definition covering all possible aspects and scenarios.

Trust establishment is a process of creating trust between two entities. Winsborough [START_REF] Winsborough | Automated Trust Negotiation[END_REF] claims that the mainstream approaches presume that the entities already know each other. Two standard approaches are used: Identity-based, when an entity is authenticated based on its known identity and capability-based, when an entity possesses capabilities needed by the requester. However, this approach does not work well in open systems, e.g. online environments, where the entities are anonymous and their attributes are unknown. In this case, trust negotiation can be used. It belongs to the trust-based decision-model concept [START_REF] Moyano | Trust Engineering Framework for Software Services[END_REF] and is a process of incrementally establishing trust by exchanging credentials, one by one between two entities. The exchange process continues until the required trust level is reached [START_REF] Winsborough | Automated Trust Negotiation[END_REF][START_REF] Winsborough | Towards Practical Automated Trust Negotiation[END_REF]. Credentials are private resources of an entity that contain sensitive information and can lead to identify the entity or to disclose facts about it. According to Winsborough [START_REF] Winsborough | Automated Trust Negotiation[END_REF] credentials or property-based digital credentials are the on-line analogues of paper credentials that people carry in their wallets. They appear to be well suited to establish trust in open systems. Credentials can also authenticate other entities, their properties and relationships. Ting Yu et al. offer another definition [START_REF] Yu | A Unified Scheme for Resource Protection in Automated Trust Negotiation[END_REF], which states that digital credentials are verifiable, unforgeable digitally signed assertions. They are signed by a credential issuer about the properties of the parties mentioned in the credential. They can also contain a public key of one or more of the parties they mention, so these parties can prove that the credentials describe them.

Policies are defined in policy languages and they are essential for trust negotiation, because they control access to credentials and protect the security and privacy of entities. In many cases policy languages are implementation dependent and there are no standard metrics to analyse and evaluate the effectiveness of these languages or to compare them [START_REF] Kumaraguru | A Survey of Privacy Policy Languages[END_REF]. Further attempts to classify policy languages have been made. Kasem and Meier [START_REF] Kasem-Madani | Security and Privacy Policy Languages: A Survey, Categorization and Gap Identification[END_REF] present an overview of languages that are suitable for security and privacy. They classify their attributes into four main categories, such as type, intention of use, scope and design and implementation details. The work in [START_REF] Kumaraguru | A Survey of Privacy Policy Languages[END_REF] classifies policy languages into the following categories: sophisticated access control languages, web privacy policy languages, enterprise privacy policy languages and context sensitive languages. Seamons et al. [START_REF] Seamons | Requirements for Policy Languages for Trust Negotiation[END_REF] present a classification that is aimed at trust negotiation. They propose many criteria that can be useful for trust negotiation, such as credential combinations, sensitive policies, transitive closure and so on. This work is similar to ours. The difference is that we chose different criteria for the language comparisons and we include more languages.

The first trust-based negotiation-model was TrustBuilder and TrustBuilder2 is its enhanced version [START_REF] Winslett | Negotiating Trust in the Web[END_REF][START_REF] Lee | TrustBuilder2: A Reconfigurable Framework for Trust Negotiation[END_REF]. Another trust-based negotiation-model is PRO-TUNE and it is rule-based [START_REF] Bonatti | A Rule-Based Trust Negotiation System[END_REF]. Trust negotiation is classified as a subclass of the trust-based decision-model concept [START_REF] Moyano | Trust Engineering Framework for Software Services[END_REF]. The models can use various negotiating strategies. PROTUNE uses a cooperative default strategy, where all the relevant and releasable information are disclosed at each step. TrustBuilder allows the entities to choose the most suitable strategy for their needs. They can choose for example the eager or the parsimonious strategy [START_REF] Winsborough | Automated Trust Negotiation[END_REF].

This paper aims to identify trust negotiation criteria and to classify policy languages against them. Kasem and Meier classified PPL, A-PPL, P2U, PRML, SecPAL4P, XPref and XACML [START_REF] Ardagna | Primelife Policy Language, W3C Workshop on Access Control Application Scenarios[END_REF][START_REF] Azraoui | A-PPL: An Accountability Policy Language, Data Privacy Management, Autonomous Spontaneous Security And Security Assurance[END_REF][START_REF] Iyilade | P2U: A Privacy Policy Specification Language for Secondary Data Sharing and Usage[END_REF][START_REF]PRML: Privacy Rights Markup Language Specification Version 0.9[END_REF][START_REF] Berker | A Framework for Privacy Preferences and Data-Handling Policies[END_REF][START_REF] Agrawal | XPref: A Preference Language for P3P, Computer Networks[END_REF][START_REF] Parducci | eXtensible Access Control Markup Language (XACML) 3.0[END_REF] as security or privacy languages, which makes them good candidates for the analysis. Seamons et al. chose for their classification of trust negotiation languages such as PSPL, TPL, X-Sec and the language of the KeyNote trust management system [START_REF] Bonatti | Regulating Service Access and Information Release on the Web[END_REF][START_REF] Herzberg | Access Control Meets Public Key Infrastructure, Or: Assigning Roles to Strangers[END_REF][START_REF] Bertino | On Specifying Security Policies for Web Documents with an XML-based Language[END_REF][START_REF] Blaze | The KeyNote Trust-Management System Version 2[END_REF], which makes them also good candidates. The other languages that seem to be valid for trust negotiation, are PlexC, the language of the Cassandra trust management system, X-TNL, ASL and HiPoLDS [18-20, 22, 26]. In the following, the language of Cassandra and the language of KeyNote will be referred as Cassandra and KeyNote, respectively. All these languages have been selected, because they have proven useful for keeping privacy of entities, the appropriate access control handling or for other models of credentials exchange.

General Concepts of Trust Negotiation

Trust negotiation belongs to the trust-based decision-model concept that uses defined rules and policies to control access to credentials and resources [START_REF] Moyano | Trust Engineering Framework for Software Services[END_REF]. It can be defined as a process of incrementally establishing trust by exchanging credentials between two entities, while they may be complete strangers to each other [START_REF] Winsborough | Automated Trust Negotiation[END_REF][START_REF] Winsborough | Towards Practical Automated Trust Negotiation[END_REF]. The entities share their credentials iteratively one by one. The first entity discloses one credential to the other one and thus builds a basic trust in the second entity and then the second entity discloses one credential to the first one achieving the same effect. The exchange process continues until the required trust level is reached.

The basic concept of the trust negotiation is depicted in Fig. 1. It shows two entities trying to establish trust in each other. Entity (1) requests a credential from another entity (2). If entity ( 2) is willing to do so, it discloses a credential to entity [START_REF] Gambetta | Can We Trust Trust[END_REF] and by this action entity (1) might be willing to disclose another credential to entity (2). This way the entities exchange their credentials and build up trust in each other. The negotiation process continues until the desired level of trust is reached and the entities are willing to disclose new credentials. Once sufficient trust has been built, the trust negotiation successfully terminates. If an entity is not willing to disclose more credentials, depending on the negoti- ation strategy, it may be asked to provide alternative credentials or the whole negotiation process is terminated without being successful.

Trust Negotiation Criteria

The criteria are a set of requirements that will guide the whole process of trust negotiation. We identified, analysed and collected the generally accepted requirements for trust negotiation from the literature. We were looking for the important criteria that are needed to accomplish or that can simplify the process of establishing trust between two entities. The requirements are defined quite generally as they should cover wide areas that can be further divided and can be mapped to diverse existing policy languages. Entities possess credentials and various resources that may contain private and sensitive data. For that reason, the requirements must ensure that the resources are protected and the conditions under which they can be accessed must be clearly defined. A set of requirements may form a policy that is a statement of intent to guide decisions and achieve rational outcomes. Entities in trust negotiation must be able to specify their own policies defining access to their private resources. For example, some negotiation strategies, such as the eager strategy, use a concept of locked and unlocked credentials, where only the unlocked credentials can be disclosed and the locked credentials may become unlocked after receiving new credentials from the other entity [START_REF] Winsborough | Automated Trust Negotiation[END_REF]. The following requirements can be identified for trust negotiation:

-Privacy of resources. This is an important requirement of trust negotiation. An entity must be confident that access to its private data will not be abused. It should not be possible to obtain the protected resources through a swindle, e.g. by providing forged credentials. The private data must not be intentionally modified by a third party. The access policy itself can lead to facts about obtaining access to credentials, so it should be protected.

-Access control to resources. This requirement partially covers the need for privacy, which is natural as it comes from a proximity of this criterion to the previous one. Entities need to manage access to their private data, such as credentials. The access control should define the conditions under which resources can be accessed. The access control management should be simple but efficient enough and it should be transparent to the entity, so the entity can be sure that its confidentiality will not be compromised. -Usage control of resources. This requirement is referred as usage control, however it is understood more broadly, like a general compliance. It partially covers the need for privacy too, which comes from its nature. As entities exchange their credentials, they establish trust. However, an entity may discover that the other one is not playing according to the rules, e.g. it is providing false information or forged credentials. In this case the entity may decide to stop the process of building trust and terminate the trust negotiation. The entity may mark the other one as a cheater and may refuse to cooperate with it in the future. -Exchange of resources. This criterion is very important for trust negotiation and also for a policy language in order to allow definitions of policies suitable for the exchange process and to support trust negotiation efficiently. The principle of trust negotiation means to exchange credentials that are the private and confidential resources of their owning entities. An entity must be provided with a secure and straightforward way of passing its credentials to another entity. An entity may use credentials and certificates exchange with an authority to verify their authenticity. -Authority. Trust negotiation may require access to an authority for the validation of credentials. In case of doubts during a trust negotiation, entities can independently communicate with a local or global authority where they can verify credentials provided from the other entity involved. The rejection of credentials has implications. The use of authorities is not mandatory for all scenarios in trust negotiation, however sometimes it can be very helpful. -Information granularity. Credentials exchanged during trust negotiations may comprise various information levels. The information contained in a credential may be too detailed and for the actual needs it would be enough to disclose only a part or a more general, less detailed version. For example, rather than disclosing the exact location information by providing the GPS coordinates, the region or the city name would be provided instead. It may be useful to support information granularity for trust negotiation, because the credential confidentiality levels can be controlled during their disclosure and thus protect the security and privacy of their owner. -Context sensitivity. Trust negotiation should take place in the context of an intended goal. Entities have diverse capabilities and they possess various skills in different fields. For this reason, the trust built is context-sensitive and it should only be used for the defined goal or for goal-related purposes. -Roles. Roles are related to context sensitivity. Entities play various roles that may determine attributes of the entities and the purpose of the entity in trust negotiation. Roles can also determine the access control to the resources of an entity.

One of the most important requirements is the exchange of resources, which is implicit in the nature of trust negotiation, where credentials are exchanged between entities. Other important requirements are privacy of resources and access control to resources that handle privacy and protection of sensitive data. Context sensitivity is important too, if the intended trust relationship is considered to be established for a specific purpose. The rest of the requirements may enrich and simplify trust negotiation in specific scenarios.

Analysis of Policy Languages

The analysis of potentially suitable policy languages for trust negotiation is presented here. The languages were chosen if their attributes seemed to be helpful, e.g. they supported security or privacy. The languages will be analysed to classify their features and then these features will be checked against the trust negotiation criteria identified in Section 4. If a match is found with a particular criterion, the language is marked supporting trust negotiation.

Privacy of Resources

The maximum privacy preservation would be to not disclose any credentials or resources to anyone. This approach is not desirable as for trust negotiation information exchange is essential. Privacy preservation contradicts the requirement of exchanging resources. Therefore, it is important to find a trade-off between the two. To preserve privacy, it is important to disclose credentials sequentially and alternately, as they are received from the other negotiator. This approach is used by P2U [START_REF] Iyilade | P2U: A Privacy Policy Specification Language for Secondary Data Sharing and Usage[END_REF], PlexC [START_REF] Gall | PlexC: A Policy Language for Exposure Control[END_REF], Cassandra [START_REF] Becker | Cassandra: Distributed Access Control Policies with Tunable Expressiveness, Policies for Distributed Systems and Networks[END_REF], X-TNL [START_REF] Bertino | X-TNL: An XML-based Language for Trust Negotiations[END_REF], HiPoLDS [START_REF] Dell'amico | HiPoLDS: A Hierarchical Security Policy Language for Distributed Systems[END_REF] and PSPL [START_REF] Bonatti | Regulating Service Access and Information Release on the Web[END_REF]. They can be configured to initially exchange fewer confidential credentials and as trust builds, more confidential ones are disclosed, thereby protecting privacy. However, we do not consider X-TNL, HiPoLDS and Cassandra to satisfy this privacy criterion as they neither explicitly provide any expressions of privacy policies nor include the preservation of privacy in their design. Other languages such as PPL [START_REF] Ardagna | Primelife Policy Language, W3C Workshop on Access Control Application Scenarios[END_REF], A-PPL [START_REF] Azraoui | A-PPL: An Accountability Policy Language, Data Privacy Management, Autonomous Spontaneous Security And Security Assurance[END_REF], P2U, PlexC, XPref [START_REF] Agrawal | XPref: A Preference Language for P3P, Computer Networks[END_REF], SecPAL4P [START_REF] Berker | A Framework for Privacy Preferences and Data-Handling Policies[END_REF], PRML [START_REF]PRML: Privacy Rights Markup Language Specification Version 0.9[END_REF] and PSPL do support the definition of privacy policies. They can be used to define the accepted maximum confidentiality level and in that way control the exposure of credentials. Each language takes a different approach. Some languages, such as PPL, A-PPL, P2U and PRML use privacy specification elements, where policies express the privacy relationships among them. Other languages, such as XPref and SecPAL4P allow entities to specify their privacy preferences, which handle the way of treating their sensitive information by a service. PlexC ensures privacy by a minimisation of the over-exposure problem. When an entity reaches the desired acceptable exposure area, the credentials disclosure risk is minimised and its privacy is preserved. This provides the best approach for privacy, because it tries to keep the exposure within desired boundaries. This is also done through a given feedback, if the boundaries are exceeded. Other languages do not provide a feedback about privacy abuse. PSPL focuses on privacy preservation of clients and servers by avoiding unnecessary disclosures. The rest of the languages, such as XACML, ASL, TPL, X-Sec and KeyNote do not provide any privacy-preserving features.

Access Control to Resources

Access control is supported by all policy languages, because each one provides a data protection and an authorised access. This criterion is given by the nature and proposed operation of policy languages. Only credentials with a certain confidentiality level can be disclosed to preserve privacy and only to the authorised entity. The attribute-based access control (ABAC) is a basic one and is supported by XACML [START_REF] Parducci | eXtensible Access Control Markup Language (XACML) 3.0[END_REF], PPL [START_REF] Ardagna | Primelife Policy Language, W3C Workshop on Access Control Application Scenarios[END_REF] and A-PPL [START_REF] Azraoui | A-PPL: An Accountability Policy Language, Data Privacy Management, Autonomous Spontaneous Security And Security Assurance[END_REF]. These languages define access rights through attribute-combining policies with the use of Boolean logic and use triggers, which are events filtered by conditions, related to an obligation. This paradigm is suitable for defining disclosure policies with respect to negotiators. It combines entity attributes with Boolean logic to implement an exchange model. The values, such as the credential confidentiality level or a list/number of disclosed and received credentials should be defined. The role-based access control (RBAC) represents another approach to access control. Disclosure policies are defined based on the entities' roles. However, complete strangers may interact with each other and if they do not take on any roles, it is impossible to make control decisions based on them. The role-based access control is used by PRML, TPL and Cassandra, where entities are mapped into roles e.g. based on issued credentials by third parties. When an entity requests permission to perform an action, its role is checked against a policy in order to permit access. Yet another approach to access control are the privacy policies used by P2U, PlexC, XPref and SecPAL4P. Access to a sensitive resource is determined based on the entity's privacy preferences. They are highly suited to trust negotiation, because an entity can maintain its desired disclosure level to protect its privacy. KeyNote uses a compliance checker that controls the disclosure of credentials. The compliance checker is an appealing solution, because it handles the disclosure decisions on behalf of the entity. A similar approach is to use personalised access rights with respect to an authorised entity. PSPL defines a client-server access control, X-TNL uses disclosure and certificate policies, ASL defines policies and authorisations managing the access control decisions, HiPoLDS defines policy domains describing a global system architecture and X-Sec manages access control to web documents. The languages, such as PlexC, X-TNL, SecPAL4P, PSPL, TPL, X-Sec, Cassandra and KeyNote make use of authorities to handle access control decisions.

Usage Control of Resources

During trust negotiation, the entities involved exchange of credentials. The problem is that once credentials have been disclosed, their owner loses control over them. Access control policies define under which conditions credentials can be disclosed. Usage control policies specify how the disclosed credentials can be used by the recipient. Usage control policies are not mandatory for trust negotiation, however, they can improve an entity's privacy in the case that it obtains a credible feedback about its credentials usage. PlexC uses an exposure control loop that provides a periodical exposure feedback to entities about the conceded access paths to their resources and how they are being shared. This feedback is then used to adjust the entity policies over time in order to prevent over-exposure in the future. It is called exposure polymorphism [START_REF] Gall | PlexC: A Policy Language for Exposure Control[END_REF]. Over-exposure is classed as when too many credentials are disclosed and their overall confidentiality is too high. PlexC may catch this situation and accordingly revise policies to prevent too many disclosures in a future trust negotiation. However, the exposure control is dynamic, non-trivial and some input values, such as the credential use after the disclosure, may be unknown. Therefore, PlexC tends to revise the policies continuously and to catch small changes in feedback. The rest of the languages neither control nor monitor credentials once they have been disclosed.

Exchange of Resources

Generally, policy languages supporting this criterion can be considered as usable for trust negotiation. The exchange of resources is a must for trust negotiation, because it is a given consequence of the process itself. Entities exchange credentials during trust negotiation and it is important that the exchange process is gradual and balanced to preserve privacy. Resources may be exchanged in large and distributed networks, such as the Internet. PlexC and Cassandra permit a trust negotiation scenario to be easily implemented in these networks. The languages, P2U, PlexC, Cassandra, X-TNL, HiPoLDS and PSPL are suitable for trust negotiation, because they allow rules for credentials exchange to be defined and controlled. Credentials are exchanged sequentially and alternately, which ensures a balanced privacy exposure of both parties. Each language can be used with a negotiation strategy that handles the exchange process, calculates the established trust from the credentials received and controls the disclosure of credentials based on their confidentiality. The strategy is not defined in the language itself, but rather in the system using the language. The Cassandra trust management system uses a strategy similar to the "Parsimonious Strategy" [START_REF] Winsborough | Automated Trust Negotiation[END_REF]. It handles the exchange process itself through agents thereby removing this responsibility from the user. PlexC and Cassandra are designed to process trust negotiations in large networks, which introduces security and privacy issues. PlexC reduces them by the over-exposure control and Cassandra follows well-defined conditions, defined by the local access control policies. The languages, P2U, HiPoLDS and PSPL use a different approach to exchange resources. P2U facilitates a user data sharing and negotiation over various applications, HiPoLDS uses reference monitors to control the exchange process among policy domains and PSPL exchanges credentials and declarations between clients and servers. The rest of the languages, XACML, PPL, A-PPL, XPref, ASL, Sec-PAL4P, PRML, TPL, X-Sec and KeyNote do not support this criterion and thus are not suitable for trust negotiation. However, TPL is extensible and provides other suitable criteria for trust negotiation, such as access control, authority and roles, so it could be extended to include this criterion.

Authority

Trust negotiation may require the presence of one or more authorities. A trusted certification authority serves to issue and verify credentials, which, in turn makes the negotiators more confident about the credentials' authenticity. A general authority is referred as it may stand for different types of authorities, however, the analysed languages do not specify the exact type of a certification authority.

It is supported by a few languages, such as X-TNL, SecPAL4P, PSPL, TPL and X-Sec. This is the basic use of authority and it can be helpful for entities involved in trust negotiation to verify the validity and the genuineness of credentials. X-TNL, TPL and X-Sec allow authorities to be organised into categories. In X-TNL and X-Sec, credentials and declarations form certificates that are collected into X-Profiles. TPL organises certificates into certification profiles and is able to automatically collect missing certificates from peer servers. Some languages, such as PlexC, SecPAL4P, Cassandra and KeyNote support a delegation of trusted decisions or actions, where the trustee can act on behalf of the trustor. These languages are designed for large decentralised networks, such as the Internet. Delegation of authority is useful here, because the requester and the authoriser may not have established a trust relationship. A disclosure decision of a trustor may be inspired by a disclosure decision of a trustee. The delegation of authority, trusted decisions or actions is also suitable for trust negotiation, because it allows entities to delegate disclosure decisions to trusted parties, such as security agents.

The Cassandra trust management system uses trusted agents to control the credentials exchange process. These agents take responsibility for actions and decisions that are delegated to them by trustors. The rest of the policy languages, XACML, PPL, A-PPL, P2U, XPref, ASL, HiPoLDS and PRML do not support this criterion.

Information Granularity

Credentials possess various confidentiality levels depending on, for example, their importance. When a credential is disclosed, its owner's privacy is automatically compromised, as far as the confidentiality allows. PlexC allows information about an entity to be disclosed with different accuracy levels. The degree of information provided can be defined by policies. For example, an entity can provide its precise position with GPS coordinates, or less accurately by disclosing only a region or a city name. Additionally, rules can be defined based on the current time or location. For example, the access to resources can be permitted, only when the entity is located in a certain region or for a certain period of time. Data can be shared with more or less precision so as to preserve privacy. PlexC may revise the disclosure policies to provide less precise and therefore less confidential information, when the entity during trust negotiation reaches the over-exposure area. The revision of policies is controlled by PlexC automatically. The rest of the languages do not explicitly support any form of different accuracy levels. They understand credentials disclosure as a binary operation, so a credential is either disclosed completely or not at all. If an entity wants to provide less confidential information, it must do so for itself e.g. by dividing the credential into parts.

Context Sensitivity

Entities that want to establish trust with each other, do so to accomplish a common goal, for a specific purpose. Each entity possesses different knowledge, abilities, skills and resources, for which the entity can be trusted to successfully participate in reaching the goal. The entity might not be trusted for another purpose, because different attributes would be required. Therefore, trust negotiation examines important attributes for the intended purpose, for which the entity can be trusted. One approach is to define purpose-dependant conditions, under which credentials can be shared or disclosed. This is the case of PPL, A-PPL, P2U, PlexC and XPref. On the other hand, PRML defines such conditions in order to control data operations, i.e. what operation on which data can be performed. This approach is more general, because it allows an entity to define its own purpose-dependant data operations. All these languages allow the purpose for the credentials exchange to be defined during the trust negotiation. If a credential is demanded for a different purpose then this is specified in the disclosure policy and the access may be denied. Concretely, PPL and A-PPL define authorisation types that can use resources only for a particular set of purposes, P2U uses the purpose-relevance-sharing principle, where only the relevant resources to the specific purpose and context of use are shared, PlexC defines context-dependant policies that influence the access traces to private data and XPref and PRML specify a purpose object for the same reasons. Unlike the others, PPL and A-PPL allow a hierarchy of the purpose elements to be created, so that Boolean logic can be applied to them, which improves and simplifies the purpose-relevant access decisions. For example, the parent-purpose element may specify that a credential may be disclosed only for establishing trust and its child-purpose element may specify in which context. The credential will be disclosed if both of the conditions are satisfied. Some languages, such as A-PPL, P2U and XPref, allow a retention value to be defined, which specifies the duration of access to a resource. This feature improves security and privacy of the resource owner. After the defined time period, the resource will be deleted. The rest of the languages are not context sensitive and do not allow purpose-relevant conditions to be specified.

Roles

As mentioned earlier, entities take part in trust negotiations to reach a common goal. Only those entities with suitable attributes become trusted to accomplish it. Entities may take on roles that are associated with their attributes, e.g. a certain role requires that an entity possesses certain features. These roles can be specified by some languages, such as XACML, PPL, A-PPL, PlexC, ASL, HiPoLDS, PRML, TPL and Cassandra. Some of them, such as XACML, PPL and A-PPL already contain some specific, predefined roles that entities can have and that control access to their resources. However, all these languages allow entities to define a new role and to perform a particular action based on it. In PlexC, roles can be assigned to a group with given permissions, which simplifies the permission management and is useful for large networks. Cassandra supports auxiliary roles that can express some attributes of their owner and can be used without an active role. HiPoLDS defines roles by assigning policy domain attributes to policy domains representing entities. PlexC, TPL and Cassandra can use an authority to issue and verify certificates about the assigned roles. The languages, ASL, PRML and Cassandra can form a hierarchy of roles. This enables a role combination to be easily defined in order to perform an action or disclose a credential. As occurs for the context sensitivity, Boolean logic is applied when forming the hierarchy of the roles. PRML allows a role to extend over multiple other roles and to inherit their permissions. Unlike the others, Cassandra supports a role retention, which means that a role validity period can be defined. After its expiration the role is no longer valid and in consequence, obtaining credentials during trust negotiation can be refused. This feature improves the security and privacy of negotiators.

5.9 Analysis Summary.

After the policy languages analysis is performed in Section 5 we can summarise our findings in Table 1. A partially supported criterion is defined as a criterion that was found as a secondary effect of other criteria supported by the language, but was not explicitly mentioned in the literature nor its presence was intended or designed by the authors of the language. Each of the languages was originally designed to solve another type of problem. Some of them already included some form of trust negotiation in their design, such as P2U, PlexC, X-TNL, HiPoLDS, PSPL and Cassandra. The best one for trust negotiation seems to be PlexC, as it is the only one to support all of the identified criteria in Section 4. PlexC takes an interesting approach. It introduces the exposure control problem and claims that there is an area of acceptable exposure. Entities try to eliminate the over-exposure of their data and tend to transform it into the most acceptable exposure that does not expose them to a major risk. For trust negotiation this means that only a minimal set of credentials will be disclosed to reach the required level of trust. The other highly recommended languages are P2U and Cassandra. P2U focuses on the purpose of data sharing, so the context is important. It simply defines the data provider, the data consumer and the relevant policies for the data exchange. Cassandra acts as a local service and it is completely decentralised. It supports roles and actions that are performed over these roles. In this way each entity has total control over its resources and policies in trust negotiation. The languages, X-TNL, HiPoLDS, PSPL and TPL support the criteria only partially. They can be used for a special or simple case of trust negotiation, but they lack its general support. All the languages except TPL support the exchange of resources, which is essential. TPL supports access control, authority and roles, but can be further extended to the exchange of resources. X-TNL although originally designed for trust negotiation, lacks some criteria, such as roles, context sensitivity and partial privacy of resources. HiPoLDS and PSPL were designed for different purposes, but their capabilities could also be used for trust negotiation. PSPL is an expressive and extendible language. The remainder of the languages, XACML, PPL, A-PPL, XPref, ASL, SecPAL4P, PRML, X-Sec and KeyNote serve specific purposes that are not concerned with trust negotiation. XACML is an attribute-based access control system, PPL and A-PPL are extensions over XACML with data handling and protection capabilities, XPref and SecPAL4P serve for users to define their privacy preferences, PRML merges the corporate privacy policies and the data handling policies, ASL serves for expressing authorisations, X-Sec protects web documents and KeyNote handles authorisations in decentralised environments.

Conclusion

In this paper we have analysed policy languages to check their suitability for trust negotiation. In order to do so, we have first identified the following criteria: privacy of resources, access control to resources, usage control of resources, exchange of resources, authority, information granularity, context sensitivity and roles. We believe them to be quite a complete list of general criteria for trust negotiation regardless that they can be refined in the future for specific purposes.

Then, the policy languages have been analysed against them. From this analysis, it has emerged that only PlexC is fully suited for trust negotiation. PlexC was found to be the only one from all the languages analysed that supports all of the identified criteria for trust negotiation. Due to its completeness and flexibility, PlexC is a good candidate to be used in the Internet of Things (IoT) trust negotiation scenarios.

A subset of the chosen languages were suitable in part, because they generally support the exchange of resources, but lack the other possible criteria demanded by trust negotiation. The rest of the languages are not suitable, because they lack the essential criterion for trust negotiation, which is the exchange of resources and other possibly important requirements too.

In the future work, the identified criteria will be divided into more finegrained criteria, if needed for specific purposes, that could match the analysed policy languages more precisely. The current criteria are quite broad, so it is a good idea to make another identification of more specialised criteria important or useful for trust negotiation. They will form a subclass of the currently identified criteria. In addition, other criteria although not directly related to trust negotiation could be taken into consideration, such as the languages syntax and user-friendliness.

Fig. 1 .

 1 Fig. 1. Trust negotiation basic concept

Table 1 .

 1 Supported trust negotiation criteria

Legend: ×: supported * : partially supported

Acknowledgements

This research has been supported by the European project "European Network for Cyber-security (NECS)" -the European Unions Horizon 2020 research and innovation programme under the Marie Sklodowska-Curie grant agreement No. 675320 and the Spanish Ministry of Economy and FEDER through the project PRECISE (TIN2014-54427-JIN).


Stefano Sebastio
email: stefano.sebastio@inria.fr

Rahul Ghosh

Avantika Gupta

Tridib Mukherjee

ContAv: a Tool to Assess Availability of Container-Based Systems

Keywords: software containers, virtualization, cloud computing, distributed system availability, simulation tools

The momentum gained by the microservice-oriented architecture is fostering the diffusion of operating system containers. Existing studies mainly focus on the performance of containerized services to demonstrate their low resource footprints. However, availability analysis of densely deployed containerbased solutions is less visited due to difficulties in collecting failure artifacts. This is especially true when the containers are combined with virtual machines to achieve a higher security level. Inspired by Google's Kubernetes architecture, in this paper, we propose ContAv, an open-source distributed statistical model checker to assess availability of systems built on containers and virtual machines. The availability analysis is based on novel statespace and non-state-space models designed by us and that are automatically built and customized by the tool. By means of a graphical interface, ContAv allows domain experts to easily parameterize the system, to compare different configurations and to perform sensitivity analysis. Moreover, through a simple Java API, system architects can design and characterize the system behavior with a failure response and migration service.

I. INTRODUCTION

Operating system (OS) containers (e.g., Docker) are widely adopted by large providers such as Amazon [START_REF]Amazon EC2 Container Service[END_REF], Google [START_REF]Google cloud platform -container engine[END_REF], Microsoft [START_REF]Azure container service[END_REF], and Netflix [START_REF]Containers at Netflix -an evolving story[END_REF] for building cloud-based solutions. Containers are created by OS level virtualization [START_REF] Soltesz | Container-based operating system virtualization: A scalable, highperformance alternative to hypervisors[END_REF] through the UNIX-like kernel resources isolation and management features. The lightweight and portable runtime environment built with containers enables the foundation for implementing microservice-oriented architectures [29]. A containerbased system is composed by a container manager (or daemon) supporting container instances (more simply referred as containers) generated from images available in a repository. Containers spawned in multiple copies, for load balancing, scaling or availability purposes, are generated from the same image (containing e.g., database management systems or web servers) and thus belong to the same type.

Recent works [START_REF] Felter | An updated performance comparison of virtual machines and linux containers[END_REF], [START_REF] Morabito | Hypervisors vs. lightweight virtualization: A performance comparison[END_REF] have benchmarked and compared OS containers versus Virtual Machines (VMs) with respect to processing, storage, memory, and network aspects. While in general containers have better performance and lower overhead, the main drawbacks for container-based solutions are

The work was done when the authors were working at Xerox Research Centre India (XRCI), Bangalore, Karnataka, 560103, India. related to security issues. To this end, a common practice is to deploy the containers inside VMs for creating a layer of security by isolation [8].

Google Kubernetes, Apache Mesos, Docker Swarm and Spotify Helios are examples of orchestration platforms for container-based systems. Note that, Kubernetes has a High-Availability version [START_REF]Kubernetes high-availability[END_REF] with two components: pods and a kubelet agent (see Figure 1). The pods are groups of containers, co-located, and co-scheduled, running in a single logical host (i.e., a VM or a physical host). The kubelet manages the pods through a health check monitor, and can spawn new containers or restart existing containers when needed.

As more enterprises implement container-based systems, the availability assessment and management aspects of these solutions are becoming important. Availability studies can be classified in two main categories: (i) data-driven analysis and (ii) model-driven analysis. Datasets are populated with failure artifacts collected through measurements of a deployed system [START_REF] Grottke | An empirical investigation of fault types in space mission system software[END_REF], [START_REF] Sebastio | Characterizing machines lifecycle in google data centers[END_REF], [START_REF] Stefanovici | Battling borked bits[END_REF] or from a system undergoing stress tests [START_REF] Grottke | Analysis of software aging in a web server[END_REF], [START_REF] Matias | An experimental study on software aging and rejuvenation in web servers[END_REF]. In the first case, the data reflect characteristics and phenomena of a real environment, whereas, in the latter, stressful conditions can be generated in laboratory having a controllable environment. Failure prediction and the evaluation of mitigation techniques can be realized by modeling the system behavior and by analyzing the associated availability. Formalisms for studying the system availability can be classified in state-space (e.g., Markov chains and Petri nets -PN) and non-state-space (e.g., Reliability Block Diagram and Fault Trees Diagram -FTD) models [START_REF] Ghosh | Scalable analytics for iaas cloud availability[END_REF], [START_REF] Kim | Availability modeling and analysis of a virtualized system[END_REF]. These models are solved: analytically (even relying on the support of software tools e.g., [START_REF] Ciardo | Spnp: The stochastic petri net package (version 3.1)[END_REF], [START_REF] Trivedi | Sharpe at the age of twenty two[END_REF]) or by simulation whenever the models are highly complex.

In this paper, we take a model driven approach for availability analysis of container-based systems, primarily due to the difficulties in collecting or finding publicly available failure artifacts. However, we conduct laboratory experiments to collect real data (as reported later in Section V) and to parametrize our analytical models. In our recent work [START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF], we proposed, designed, modeled and analyzed some containerbased solutions for studying system availability through FTD and stochastic PN. The models in the aforementioned work become too complex to be solved analytically or with the aid of stochastic modeling software tools such as SPNP [START_REF] Ciardo | Spnp: The stochastic petri net package (version 3.1)[END_REF] due to increasing number and type of containers which eventually lead to state space explosion problem.

Contributions. This paper presents an open-source simulator ContAv to support availability analysis of container-based solutions. Striking a balance between the ease-of-use and flexibility, ContAv provides two key features: (i) through its GUI, the tool enables the domain experts to perform sensitivity analysis and to compare different deployment configurations (hiding the models complexity); (ii) system architects can use a simple Java API to have the desired flexibility in designing, testing and evaluating failure mitigation and migration strategies. ContAv is based on distributed statistical model checking for performing quantitative analysis on the system properties [START_REF] Sen | On Statistical Model Checking of Stochastic Systems[END_REF]. By using ContAv, a cloud practitioner is relieved from the hurdles encountered in generating and solving the analytical models of container-based deployment environments. Other than automatically generating the models, compared to the existing stochastic modeling tools (e.g., SPNP), ContAv provides model checking and distributed simulation functionality, and a higher abstraction of the functions for managing the containers behavior via a Java API.

Structure of the paper. The paper is structured as follows. In Section II the considered container-based configurations are discussed. The ContAv architecture is presented in Section III, whereas some implementation details and the validation results are reported in Section IV. Section V shows a case study in which a sensitivity analysis is performed and some of the ContAv APIs are described. Finally, Section VI concludes the work with some final remarks and outlines our future efforts on improving the tool.

II. CONTAINER-BASED SYSTEMS

Containers can be deployed in multiple instances for load balancing, scalability or availability purposes. To overcome the well-known security risks, exacerbated in densely deployed environments, a common practice contemplates the use of VMs for creating sandboxes around group of containers [8]. From this observation and studying the Google's Kubernetes architecture [START_REF]Kubernetes high-availability[END_REF], in our recent work [START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF], we discerned three configurations named consolidated, homogeneous and heterogeneous therein. A pictorial representation of these three configurations is depicted in Figure 2. The simpler setup is represented by the consolidated configuration (Figure 2-a), in which all the containers are grouped in a single environment. A single container daemon is thus in charge to manage all the containers. This setup has the benefit of requiring less computational resources than the other configurations at the price of losing the security isolation provided by the VM. It is thus recommended to use the consolidated configuration in scenarios without security concerns or with scarce hardware resources.

The other two setups envisage a security via VM isolation approach. In the homogeneous configuration (see Figure 2b), containers are grouped within VMs according to their type. This setup is thus suitable for a public cloud in which users run several instances of the same container in their own VM, for load balancing or availability, but are not willing to share their VMs for security concerns or pricing issues. An isolation by container type is achieved. Therefore, this setup is advised for all the scenario in which security is a key feature and can not be assured in the same way for all the container types.

Lastly, the heterogeneous configuration (see Figure 2c) groups the containers in VMs according to the instance number. This setup can be adopted in a corporate cloud in which all the containers comply with the same security policy. With respect to the homogeneous configuration, in this case a VM failure does not affect the service availability, and the system can be kept working even if a VM reboot is required (e.g., to apply security patches).

As any researcher with hands-on experience on cloud containers could recognize, all the widely used container based platforms [START_REF]Amazon EC2 Container Service[END_REF]- [START_REF]Containers at Netflix -an evolving story[END_REF], [START_REF]Google cloud platform -container engine[END_REF], [START_REF]Kubernetes high-availability[END_REF], such as Google Kubernetes, from a deployment perspective are organized around the heterogeneous or homogeneous configuration presented in the paper (others configurations are subcases of these and can be easily obtained through the ContAv API by selectively removing containers from the VMs).

Having multiple instances of the same container running, it is possible to define the system available when at least k out-of N instances are working for each container type (where k and N could be different for each container type). In this regard, it is worth noting that the container operation is subjected to the functioning of its manager. Containers can thus fail for an internal problem but also due to problems affecting the environments that execute and control them i.e., manager, hypervisor and VM (if present), OS, or hardware. In [START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF] we present the Fault Tree Diagrams for all the three configurations, to highlight their substantial difference from an availability point of view. E.g., the availability of a given container type depends, in the heterogeneous configuration on the status of all the VMs (see Figure 3), whereas the homogeneous configuration has a single pointof-failure represented by the VM running all the containers of such a type (see Figure 4).

In case of container failures, it is possible to instruct the manager to automatically restore the container e.g., through the "autorestart" flag of the Docker implementation. Whereas, to Fig. 5: Failure response and migration service.

recover the system in case of failures of any other component, the only feasible approach is to resort to an external component similarly to the Kubernetes in high availability configuration. We thus envisage a kubelet-like agent running in a different machine. Its action is limited to restart the manager, in case of failure of such a component. Whereas, since the VM restart is a moderately slow process, the kubelet-like agent has the chance to carry out several failure response and migration service strategies in the event of VM failures. In particular, another VM can be selected to temporary spawn and host a certain number of container instances to overcome the lack of the failed VM. At a later time, when the original VM is restored (together with its container manager), thanks to the orchestration of the kubelet-like agent, those backup containers can be migrated back resorting to the container live migration functionality [START_REF]CRIU integration in Docker[END_REF], [START_REF] Mukherjee | Haul an engine for containers live migration[END_REF], [START_REF] Emelyanov | Live migrating a container: pros, cons and gotchas[END_REF]. The supporting VM will manage the backup containers as its own, thus restarting them in case of failures. A pictorial representation of the failure and migration support is presented in Figure 5.

Since several strategies can be exploited for the failure response and migration service, our simulator allows to design and test new approaches through a simple Java API, as described in the following Section V.

III. CO N TAV ARCHITECTURE

In this section the ContAv architecture is illustrated. First, the tools underlying ContAv are presented, then the ContAv functionalities are described through an Unified Modeling Language (UML) use case diagram, and finally an UML activity diagrams make explicit the internal workflow of ContAv.

ContAv is built on top of DEUS [START_REF] Amoretti | Simulating Mobile and Distributed Systems with DEUS and ns-3[END_REF], an open-source, Java-based, general-purpose discrete event simulator (DES). Among the different freely availably DES, our choice fell on DEUS for its flexibility on supporting analysis of every kind and size of complex systems. DEUS is constituted by three basic elements (reflected in an equivalent number of founding classes): (i) nodes, the entities interacting in the system; (ii) events, defining the internal actions and interactions among the nodes or with the environment; (iii) processes, determining the occurrence of the either stochastic or deterministic events. DEUS foresees a model described in Java and a scenario (i.e., the parametrization of the processes) in XML.

We enhanced DEUS with MultiVeStA [START_REF] Sebastio | MultiVeStA: Statistical model checking for discrete event simulators[END_REF] an efficient distributed statistical model checker (SMC) which can be easily integrated with any DES. System properties of interest can be compactly asserted by means of the MultiQuaTEx quantitative temporal expressions. MultiQuaTEx queries are evaluated by the SMC running simulations distributed on multiple cores or physical machines, and evaluated against the significance level and the Confidence Interval (CI) size computed with the Student's t-test.

Through the SMC, it is possible to formally specify system properties such as the total outage time in a year, the number of container, container manager, VM, hypervisor and OS failures, and the number of failure and migration requests. For all the specified metrics, MultiVeStA runs independent simulations until the first of the following conditions is attained: reaching the required CI for all the MultiQuaTEx queries and achieving the maximum number of runs. Whenever the system metrics are gauged at different points in time, a comma-separated value (CSV) file is also automatically produced. The ContAv GUI allows to easily setup the analysis of interest and then compare the results graphically (e.g., after a sensitivity analysis). The analysis output can be exported as gnuplot, PNG or CSV file.

All in all, we built a toolchain coinciding with the one recently proposed for the volunteer cloud simulator AVo-Cloudy [START_REF] Sebastio | AVOCLOUDY: a simulator of volunteer clouds[END_REF].

A. ContAv use case diagram

The UML use case diagram in Figure 6 describes the ContAv functionalities and how the different actors interact with the tool. Despite the open-source nature of the tool, in ContAv actors could interact with the core (the simulator itself) simply through the abstraction provided by its services. ContAv envisages three possible actors interacting with it. Experts on distributed and container-based systems are in charge of defining the OS containers configurations (Setup) and parametrize the scenario (Configuration) according to the properties of the system under study. Decision makers will compare the system performance (Comparison) against several configurations or after having performed a sensitivity analysis. System architects can work at a lower level designing and implementing the failure response and migration service strategies (as described later in Section V) that will be subsequently analyzed by the other actors. The Analysis use case depends on the simulator model and in turn on the way it has been designed and configured.

The interaction with all the functionalities shown in the use case diagram can be abstracted at a higher level taking advantage of the GUI provided by ContAv. The latter presents the use cases: setup, configuration, analysis and comparison with a tabbed interface (see Section IV). As already mentioned, the only feature that could require code writing is the failure response and migration service, if design and test of novel solutions are deemed.

B. ContAv activity diagram

In this section the internal workflow of ContAv is explained by means of the UML activity diagram in Figure 7, in case the tool is used through its GUI.

At first, the user must setup the configurations of interest among the ones presented in Section II or user-specified through the Java API. Then, the input parameters for configuring the scenario and the SMC features must be provided. For the scenario parameters such as Mean Time to Restart (MTTR) and Mean Time to Failure (MTTF), ContAv provides default values computed during experiments in our laboratory or from literature, as later reported in Table I of Section V. The parameters required by the distributed SMC are instead: number of simulations performed in parallel, batch size, maximum number of simulation runs, significance level and confidence interval size.

Once the setup is ready, the SMC can start the quantitative statistical analysis loading the scenario and the system properties of interest. According to the specified degree of parallelism MultiVeStA will start independent and distributed simulations exploiting the cores parallelism or the available machines. In the latter case, users need to fill in the serverlist file with a list of IP address -TCP port pairs running the DES engines. Simulations are performed until the first of the following conditions is reached: the statistical analysis has an accuracy less or equal to the requested CI, or the maximum number of runs is obtained. Readers interested about the performance scaling achievable integrating MutliVeStA with a DES can refer to [START_REF] Pianini | Distributed statistical analysis of complex systems modeled through a chemical metaphor[END_REF] in which a deeper analysis is presented.

ContAv users can perform sensitivity analysis by simply choosing the parameter(s) of interest from a drop down menu and specifying range, maximum and minimum values, whereas the tool will be responsible for automatically generating all the corresponding scenarios. Several sensitivity analyses can be requested at a time.

Finally, it is possible to graphically compare results from different configurations and sensitivity analyses through an interactive plot widget. Results for each scenario are saved as CSV, whereas any additional data and plot produced during the comparison can be exported as PNG, gnuplot, SVG or CSV file.

IV. CO N TAV IMPLEMENTATION

ContAv models are based on the Stochastic Reward Nets (SRNs) and FTDs designed in our recent work [START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF]. The FTDs provide an overview on the interdependencies of the For instance, in the FTD of the heterogeneous configuration (see Figure 3 in Section II and [START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF]) it is possible to identify three layers. In the bottom layer, availability of container manager, VM and the one of all the containers of the same type are OR-ed (i.e., in this configuration an OR gate is required for each container type running in each VM). The central layer is constituted by as many voting OR-gates as the number of container types in the system (to obtain the availability of a k out-of N configuration), in which the input parameters are the gates of the lower layer. The topmost layer considers instead the availability of containers (originated from the aforementioned gates), hypervisor, OS and can be easily extended to consider also hardware components.

An example of the SRN for a single VM in heterogeneous configuration (without the failure response and migration service) and constituted by only two types of container, is reported in Figure 8. The SRN places and transitions required for each container type are identified by the dashed selection in Figure 8. As the number of containers and/or their type increases, the model will incur in a state space explosion and even tools such as SPNP can not be of any help (since the reachability graph needs to be built in memory). For the homogeneous and heterogeneous configurations in which a failure response and container migration service is implemented, the underlying SRN models are very complex (see [START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF]), a node-by-node (i.e., VM) decomposition can not be adopted and thus the system turns out to be analytically intractable. The only viable solution in these cases is resorting on the Monte Carlo simulations on which the SMC is based on. ContAv is the first tool tailored for studying availability of container solutions extracting away all the hurdles faced by a cloud practitioner in generating these models.

In Figure 9 a screenshot of the tabbed interface designed around the use cases discussed in the previous Section III is presented. The system availability and the number of tasks lost are two fundamental availability metrics for a container-based cloud (see Google's Borg [START_REF] Verma | Large-scale cluster management at Google with Borg[END_REF]) captured by ContAv. Other measures e.g., downtime, charge-back for customers, loss of productivity, and operational cost of re-running the tasks are derived from the first. Noteworthy, ContAv users can easily study and compare container-based configurations answering to questions such as: "Having a certain configuration, how many container instances are required to achieve an availability of at least x%?" or "Which configurations are the best wishing to spawn a given number of containers?".

To validate the simulator, we compare the ContAv solutions with the analytical solution using SPNP [START_REF] Ciardo | Spnp: The stochastic petri net package (version 3.1)[END_REF] and the SHARPE tool [START_REF] Trivedi | Sharpe at the age of twenty two[END_REF] for certain configurations. Figure 10 shows the relative error of ContAv with respect to the analytical solution varying the number of containers for the monolithic models in which a single container type is present and no failure response and migration service is available. The ContAv percent relative error is of about the 0.02% running only 100 simulations. Obviously, the time taken by the simulator is greater as higher is the required accuracy. The beforehand discussed model complexity prevents us to derive the analytical solutions for more complex scenarios.

V. CASE STUDIES

To provide a starting point for the model parameterization, we populate the configuration tab of the GUI with some default values (see Table I). These parameters are either computed from experiments on our enterprise private cloud system or acquired from public data [START_REF] Hellerstein | Google cluster data[END_REF], [START_REF] Kim | Availability modeling and analysis of a virtualized system[END_REF]. In particular OS, hypervisor and VM values have been extracted from [START_REF] Kim | Availability modeling and analysis of a virtualized system[END_REF]. The container availability has been computed from the Google dataset [START_REF] Hellerstein | Google cluster data[END_REF] considering how Google maps each task in a Linux cgroupbased resource container [START_REF] Verma | Large-scale cluster management at Google with Borg[END_REF] (on top of which the Docker containers are built). Each value computed in our laboratory is the average of 1000 experiments on a server equipped with Since in the aforementioned table the container manager failure rate is due to an arbitrary estimation, in this section we performed a sensitivity analysis on this parameter through ContAv. The k out-of N availability is instantiated assuming that the system is considered up if, for each of the two types of container, at least the 80% of its initial 100 containers are running. Seeing as how the Google's Borg [START_REF] Verma | Large-scale cluster management at Google with Borg[END_REF] runs tasks in containers, in the following analysis we are interested on knowing the dependency of the tasks lost (i.e., any OS process wrapped under a container) from the container manager failure rate. Results of the sensitivity analysis are shown in Figure 11. From the plot it is possible observing that, increasing the mean time to failure for the container manager, for each of the three container-based configurations, the tasks lost are reduced. Performance is stabilized when the container manger has a mean time to failure of about 2000 hours. Over this values the performance improvement is only marginal. For a meantime-to-daemon-failure of 5000 hours, the homogeneous configuration has lost almost 1000 tasks more than the other configurations. This is an example of how ContAv makes a deployment decision failure-aware.

In the beforehand considered analysis, we assumed that all the mean time to failures were referred to a Poisson distribution. Exploiting the ContAv toolchain (as described in Section III) we can easily modify the process definition just by calling a different handler. E.g., in Listing 1 is reported a snippet of the XML file defining the simulated scenario, and particularly the process definition of the container manager failure. The distribution can be changed In a densely deployed container-based system, VM nodes can cooperate for realizing failure response and container migration strategies. As described in Section III, system architects can design and test such strategies with ContAv thanks to its Java API.

Failure response strategies can be designed implementing the failureSupport() function. Such a function is called by the kubelet-like agent on a VM failure. As a basic example, the implementation for a uniform random selection is shown in Listing 2. A list containing all the working nodes (i.e., with running VM and container manager) is created (see line 3). Then, a working node is randomly selected calling the selectNodeForSupport() function (see line 13). Finally, the request is forwarded to the support node through the askFailureSupport() ContAv API function (line 8). More complex strategies can be implemented following these steps.

Similarly, migration back policies can be implemented through the migrateBack() ContAv API. A Javadoc attached to the tool provides a full description of all the functions available in ContAv.

Listing 2: Failure mitigation with random selection startegy

VI. CONCLUSION AND FUTURE WORK

This paper introduced our distributed statistical model checker ContAv. ContAv is a first-of-a-kind availability analysis tool for containers capturing enterprise grade deployment configurations and providing a scientific modeling approach while hiding the details to users. The simulation models have been designed by means of Stochastic Reward Nets and Fault Tree Diagrams recently proposed by us in [START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF], and validated against the analytical solution.

ContAv is publicly released as an open-source tool, enriched with a full set of default parameters computed from experiments on our enterprise private cloud, and has a twofold use. System architects can use the simple Java API to design new failure response and container migration strategies, whereas domain experts can interact with the GUI and parametrize the system to quantitatively compare system configurations and perform sensitivity analysis. Through a whatif analysis performed with ContAv, cloud administrators can judiciously use costly resources (e.g., servers, VMs) that can increase redundancy and create careful deployment strategies.

We plan to extend ContAv in many directions. The model can be extended to systems consisting of many physical nodes in the same network, and considering resource constraints in the case in which containers have associated resource requirements. Moreover, performability aspects can be considered in the model. We are also evaluating approaches to enhance the ContAv statistical model checking capability: including the steady-state analysis with the batch means method [START_REF] Steiger | Asap3: A batch means procedure for steady-state simulation analysis[END_REF], and managing rare events during simulation through importance sampling or splitting.

Fig. 1 :

 1 Fig. 1: Google Kubernetes architecture.

Fig. 2 :

 2 Fig. 2: OS Containers configurations. CM is the container manager (daemon), the lines represent the container instances (e.g, spawn for replication), whereas each line style represent a different container type (i.e., generated from a different image).

Fig. 3 :

 3 Fig.3: Fault level diagram for the heterogeneous configuration (from[START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF]).

Fig. 4 :

 4 Fig.4: Fault level diagram for the homogeneous configuration (from[START_REF] Sebastio | An Availability Analysis Approach for Deployment Configurations of Containers[END_REF]).

Fig. 6 :

 6 Fig. 6: ContAv UML Use Case diagram.

Fig. 7 :

 7 Fig. 7: ContAv UML Activity diagram.

Fig. 8 :

 8 Fig. 8: SRN Model for a VM hosting two type of containers in heterogeneous configuration. From the bottom, availability of: VM, daemon, and container type C1 and C2.

Fig. 9 :Fig. 10 :

 910 Fig. 9: ContAv GUI: Analysis tab.

Fig. 11 :

 11 Fig. 11: Sensitivity analysis on container daemon failure rate.

TABLE I :

 I Default input parameters of ContAv API1.22). The container restart corresponds to the Docker START command, whereas the failure response assumes the RUN of a new container once, if needed, an estimated time of 2 mins to LOAD the Ubuntu container image available on "The Docker Hub" (e.g., downloading its 120 MB file size with an ADSL 8 Mbit/s) is elapsed. Being the migration a feature currently under development for Docker, we computed the sum of PAUSE, COMMIT (on the original node) and UNPAUSE as the migration time.

	Parameter	Value
	OS steady state availability (os)	0.99977
	Hypervisor steady state availability (hypervisor)	0.99989
	mean time to container failure (1/λCi)	1258 hours
	mean time to container restart (1/µCi)	0.238 secs
	mean time to container manager failure (1/λ d )	2516 hours
	mean time to container manager restart (1/µ d )	0.255 secs
	mean time to VM failure (1/λv)	2880 hours
	mean time to VM restart (1/µv)	5 mins
	mean time to orchestrate the failure support for node i on node j (1/δ iSendReqT oj ) 1 sec
	mean time to load container of type i on node j (1/δ loadiT oj )	2 mins
	mean time to run container of type i on node j (1/µruniT oj )	0.275 secs
	mean time to migrate back container of type i from node j (1/ωmigrateCiF romj )	0.140 secs
	2 Intel Xeon CPU E5-2698 v3, 322 GB of RAM running
	Ubuntu 14.04 LTS (Linux 3.13.0-24-generic x86 64) and
	Docker 1.10.1 (

  1 public void failureSupport() { 2 ArrayList<Node> workingNodes = new ArrayList<Node>(); 3 Model.nodes.parallelStream().filter(n -> (!n.vmOut && 4 !n.daemonOut).forEach(n -> workingNodes.add(n)); 5 6 if (workingNodes.size() > 0){ //start the failure resp.

	7	Node node = selectNodeForSupport(workingNodes);
	8	askFailureSupport(containerTypeToSpawn,
	9	numOfContainersToSpawn, node);
	10	}
	11 }
	12
	13 public int Node selectNodeForSupport(ArrayList<ModelA>
	14	workingNodes){
	15	int nodeToAsk = Engine.getDefault().getSimRandom()
	16	.nextInt(workingNodes.size());
	17	return workingNodes.get(NodeToAsk);
	18 }

ACKNOWLEDGMENT

The first author would like to thank Prof. Axel Legay of Inria Rennes Bretagne Atalantique (France) for his support.