{'fraction_non_alphanumeric': 0.024809320258151035, 'fraction_numerical': 0.0014248596094208364, 'mean_word_length': 5.137860082304527, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
MD-UCON: A Multi-Domain Access Control Model for SDN Northbound Interfaces

In SDN (Software Defined Network) environments, for the security considerations of the upper-layer application behaviors, we need to consider adding an access control mechanism to the northbound interface of the SDN control layer to limit the capabilities of the upper-layer applications, thereby improving the security of the SDN. In addition, considering the performance and management requirements of SDN, access control features including cross-domain support should be considered. In this paper, we proposed an MD-UCON access control model with role mechanism extension based on UCON and role-based access control mechanism. At the same time, we introduced a cross-domain role mapping method to support cross-domain access authorization, thereby enabling the model to be applied to the application of access control for the SDN northbound interface.


RELATED WORKS
The works related to this paper includes researching on the access control of SDN northbound interface in multi-domain SDN environment, proposing the role extended multi-domain access control model, researching cross-domain role conversion mechanism in multi-domain scenarios.
In previous researching, some research efforts attempted to provide access control for SDN northbound interfaces or SDN upper layer applications to improve SDN security. Canini et al. implemented the security verification of third-party SDN applications by means of attribute checking and symbolic execution. However, the proposed verification is not dynamic monitoring at runtime, and the verification is mainly for a single SDN application scenario [14]. Sherwood et al. sliced and partitioned the control logic of different users on the control layer to provide access control based on certain rules for user access, but this processing method can only isolate the control logic between different users [15]. Wen et al. assigned permissions to the commands that can be used by the application layer, which realized the isolation between the application and the control layer kernels, and improved the security and stability of the control layer. The research focuses more on preventing all upper-layer applications from destroying the underlying network. There is no access control for different policies for multiple applications [16].
In particular, Klaedtke et al. proposed an access control scheme for SDN upper-layer applications [17]. The research proposed to use network users as the subjects, and use information and configurations, including statistics, flow rules, as objects. The rights are defined as the set of reading operations and modifying operations. And, the concept of strategy is introduced. The scheme is largely in line with UCON components, such as subject, object, authority, and authorization. This research provides a reference for the work of this paper.
Since previous researches on SDN access control did not adequately consider the need to support scenarios include multiple domains and multiple SDN applications, especially for requirements in multidomain scenarios, a further research work is still needed.

UCON
The Usage Control (UCON) model was first proposed by Park and Sandhu in 2002. UCON integrates the traditional access control, trust management and digital rights management. In terms of access control, UCON covers traditional DAC, MAC and relatively advanced RBAC. The UCON model extends the traditional access control and defines three decisive factors: Authorization (A), Obligation (B) and Condition (C), and brings continuity and mutability to UCON innovatively. This allows UCON to adapt well to highly dynamic, continuously changing scenes.
The UCON model consists of six elements, including subjects, objects, rights, authorizations, obligations, and conditions. The UCON model can be shown by figure [1]. Subjects are entities that contain attributes, holding the rights to subjects. Objects are entities who also contain attributes, who subjects hold rights on. Rights are privileges on accessing objects, holding by subjects. Authorization are a set of rules that should be satisfied before the subject accessing the object. Obligation is the mandatory requirement that the subject must accomplish before accessing the objects. Conditions is a set of decision factors that are verified before subjects accessing the objects. Compared to traditional access control models, UCON's most outstanding feature is the continuity of decision and mutability of attributes. Continuity of decision means that the control strategy can be executed before and during the access. The control decision component can perform verifications in these two phases, called pre-decision and ongoing-decision. Mutability of attributes means that attributes of subjects and objects can be updated as accessing results. Attribute updates include preupdates, ingoing-updates, and post-updates. The updating may cause the system to perform actions, including allowing or revoking access rights. Figure [2] shows a completed use process with three phases in time: before-usage, ongoing-usage and after-usage.

Introduction of MD-UCON
In this section, we proposed a Multi-Domain Usage Control (MD-UCON) model by extending the basic UCON model, thereby supporting cross-domain accessing. First, we introduced the domains entities, which are corresponding the real-world domains, so that the real domains factors can be suitably modeled. Then, we introduced attributes and mechanisms from role-based access control (RBAC), simplifying the complexity of access control mechanism when facing the multi-domain scenarios; Finally, we introduced a cross-domain role mapping mechanism to resolve the problem that the crossdomain access cannot be directly dealt due to the independence of roles from different domains.

Components of MD-UCON
MD-UCON introduced the concept of domains, which can divide all subjects and objects into finite groups. Therefore, each subject has a property called subjectDomain that represents the domain in which the subject resides; each object also has an attribute named objectDomain that represents the domain in which the object resides. The domains in the model are entities that can hold some attributes, corresponding to real-world domains. For example, in a general SDN deployment, all network elements managed by the same controller, as well as all upper-layer applications directly accessing this controller, belongs to the same domain. According to whether the domain attribute of the subject and object are the same, the access from subject to object can be divided into two categories, intra-domain access and cross-domain access. MD-UCON also introduced the concept of role, which is a key attribute of the subject and is used for the authentication process of access control. A role is an entity that can contain some attributes. It has a many-to-many relationship with the subject. Each subject has a property called subjectRoles that represents a collection of role attributes held by the subject. When the access occurs, the access control system queries the role attribute set of the access subject. If any of the role attributes meet the permission requirements of the current access, the authentication succeeds. Due to the existing relationship between the role and the subject and the relationship between subject and the domain, the role and the domain also have an indirect many-to-one relationship, that is, a domain may contain a finite number of different

Cross-Domain Role Mapping
The purpose of the cross-domain role mapping mechanism is to solve the problem that role-based access control systems cannot be directly applied to cross-domain access scenarios. The traditional intradomain role mapping policy can be divided into three categories. The first is the default policy, that is, any external domain role is mapped to a default role in the local domain. In the common case, the default role is the minimum privilege role of the domain. The second is the explicit policy, that is, separated role association, the administrator clearly defines the mapping rules of the external domain role to the local domain role. The third is the implicit policy, that is, after the transfer association mechanism is introduced, a certain implicit policy can be derived from the explicit policy and the role inheritance relationship.
Considering that in the SDN environment, the default policy obviously does not meet the requirements in terms of flexibility; the explicit policy requires the administrator to clearly know all possible roles in different domains and set mapping rules for all possible roles, so the feasibility is unacceptable in practical applications. The implicit strategy with role inheritance may cause the role conflict problem to occur when the rules are set incorrectly. At the same time, the role inheritance mechanism makes the role adding, editing, deleting and other operations have a high complexity in system implementation, and there is also a large system overhead in terms of performance at runtime, therefore using of the strategy should be carefully considered.
In the access control scenario for the SDN northbound interfaces, the authentication rules and the role attributes of the upper application are generally set by trusted administrators. The upper application only holds an immutable access credential, and cannot forge the role and fraud permissions by itself. Under such premises, we can use a new role mapping strategy. We can pre-set a set of public roles in the global scope and raise requirements for each domain: first, any role in any domain must be able to be mapped to a global role; second, each domain is required to has the ability to deal with global roleseither by setting permissions for all global roles, or providing mapping rules for all global roles. By using a global role which can be understood by any domain as an intermediate role, it is guaranteed that any subject can be understood by the access control system when cross-domain access occurs. Since the number of global roles is limited and usually is relatively small, and role rules are easy to set, resulting in a good feasibility of this strategy. Therefore, we solved the problems that the traditional role mapping strategy is not flexible enough and the complexity is too high to be applied.

Formal Model Definition
The formal definition of MD-UCON is shown as follows: 1) S represents a finite set of subjects. subjects are entities that initiates access, having role attributes and domain attributes, and may also include general attributes for extension. A user in the SDN network may serve as a subject; 2) O represents a finite set of objects. Objects are the accessed entities, having domain attributes, and may contains general attributes for extension. The statistical information, configuration, flow rules, etc. in the SDN network can be used as objects; 3

CONCLUSIONS
In this paper, the MD-UCON model is proposed by extending the UCON model, to support the access control for the SDN northbound interface, and support the cross-domain access control in multi-domain scenarios. The model introduces the domain entity to enable the modeling of the domain in the real world. By introducing the role entities and the corresponding mechanisms, the complexity of the subject attribute is reduced, and the settings of access control rules are enabled. Finally, the cross-domain role mapping mechanism is introduced, achieving access control in a cross-domain access scenario. Compared with the traditional access control model, MD-UCON meets the requirements of SDN northbound interface access control, with higher flexibility and finer granularity of control, while ensuring a lower complexity, therefore it's more suitable for SDN northbound interface access control with multi-domain requirements.