Scenarios and Potential Future Work of Enterprise Network Policies

A network policy is a set of rules that govern how network resources are accessed, utilized, and secured within an organization's infrastructure. These policies outline acceptable and unacceptable behavior regarding network usage, data transmission and access control. etc. In modern digital infrastructures, network policies play a crucial role in ensuring the performance, security and reliability. For network policies used for enterprise networks, the organization's specific needs and circumstances need to be considered during the development process. For example, there are some businesses that may require high network QoS guarantees; others may require very strict access control, and so on. In addition, enterprise network policies need to be customized according to the size and complexity of the organization. For example, SMBs (Small-Medium-Businesses) usually lack a well-developed IT team and capabilities, and rely more on network policies, and even hope that the network system can be integrated with all the digital infrastructure control functions; whereas, large enterprises usually have a strong IT team, and may hope that the network policy can be easily integrated into the IT process. In this document, we focus on two common types of network policy scenarios for enterprise networks, e.g. access control and service QoE assurance, and some initial analyze of the current state of the art technologies, including GBP, IAM for access control, etc., is made. Finally, this document proposes potential future work, which mainly refers to the formation of a comprehensive "policy plane" for enterprise networks including aspects of policy management, corresponding information distribution and policy enforcement mechanisms in data plane.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Access control policies for enterprise networks are mainly used to manage and control users/devices access to applications and enterprise network resources, and include the following major application scenarios: Authentication and Authorization: Enterprise networks need to ensure that only authenticated users and devices can access corresponding data and resources. Common authentication methods include usernames and passwords, two-factor authentication, biometrics, and so on. Authorization, on the other hand, identifies the resources and permission levels that each user or device can access. Network security domain segmentation: According to the organizational structure and security requirements of an enterprise, the network can be segmented into different zones or virtual networks, with different access control policies for each zone. For example, segregate the internal network from the external network, or separate the networks of different departments. Security Measurement and Auditing: Enterprises should log the network activities of all users and devices, and conduct regular audits to detect anomalous behaviors and security vulnerabilities to help them track and respond to security incidents. For example, when enabling remote users to access the corporate network using a VPN, organizations might need to monitor remote user activity based on user identity, device health status, and other factors. In current practice, Role-Based Access Control (RBAC) approach is commonly used in enterprises for access control, which could significantly simplify the complexity of administrators' management of user privileges. Based on RBAC, Attributes-Based Access Control (ABAC) approach is also emerging, which allows finer granularity of privilege management by also considering users' attributes (e.g., users' location, device hardware/software environment, the time of access etc.) along with the role and identity.

QoE (Quality of Experience) assurance policies are to ensure the performance, stability and reliability of network services to improve user satisfaction and experience. There are some popular scenarios with more pronounced demands for QoE within the enterprise today: General traffic classification and optimization: there are different types and sources of traffic in an enterprise, including data transmission, web browsing, video streaming etc. Traffic needs to be classified according to its priority to maximize the use of limited network resources. Video conference: In the post-pandemic era, video conference is becoming more and more indispensable in daily work. In order to guarantee the smooth video conference experience, it is necessary to ensure that network bandwidth, latency and jitter are controlled within reasonable range to avoid problems such as video screen lag and voice delay etc. Remote access: Working from home or during the business trip is also becoming more and more indispensable. The ultimate goal for remote access is that it works just like within the enterprise, which also requires a reasonable network bandwidth/latency etc. Cloud applications: With the popularity of cloud-based applications, organizations are demanding higher availability and performance. Enterprise networks need to reserve sufficient bandwidth and resources for more and more frequent and intense traffic caused by cloud applications.

GBP is firstly defined by OpenStack , it allows administrators to manage network traffic and policies based on applications, services, or user groups, rather than the traditional IP address or port-based approach. With GBP, administrators can have more flexibility in managing the network, improving security and performance. In theory, GBP is a concept containing broad semantics, which could cover both access control and QoE assurance aspects of the scenarios described in , but the most prominent use case of it is access control, as described below. In enterprise networks, employees are usually categorized into various security groups. By employing GBP, enterprise networks could stop threats by ensuring that security group policies are consistently applied across the network, regardless of where endpoints or users are located. Specifically, there is VxLAN-based GBP work had been adopted by multiple vendors and applied many organizations, which utilizes a reserved field in the VxLAN header as the Scalable Group Tag (SGT). Using SGTs as match criteria in switch/firewall filtering rules is more robust than using ports or MAC addresses to achieve a similar effect. SGTs can be statically assigned or be configured on the RADIUS server and sent to the switches via 802.1X when the user is authenticated. There is an IETF draft tacking this issue and trying to standardize the approach.

IAM is a system of managing user access to systems, applications and network resources. It includes authentication, authorization, privilege management, and auditing functions designed to ensure that only authorized users can access the resources they need. IAM system is usually deployed on the application/cloud/data center side of the network, and it is becoming the de-facto approach of access control for modern enterprise mostly because of to the trend of cloudification. However, there are obvious limitations of IAM for access control: Architecture level: IAM is designed for user-to-application resource access control, but with zero control over network resources, there is significant risk exposure. Specific risk scenarios: User's east-west access is completely out of control. The IAM has no ability to sense and control the risk of illegal horizontal access/network attacks and user movement. Attack traffic cannot be blocked at the edge. The rise of IoT within the enterprise and the demand for ubiquitous user mobility has led to an increasing risk of attack traffic at the local edge, and the IAM, being deployed on the application/cloud side, is also incapable of blocking such attack traffic at the edge, thus easily causing a single point of stress and failure. ABAC implementation constraints: In the ABAC scenario described in , there are many user-side attributes (e.g., access method, user's geographic location, device environment, etc.) that are difficult to be sensed on the IAM side, and thus effective access control based on these attributes is not possible. Therefore, network-based access control is still very necessary in the context of the widespread use of IAM. Especially for the large amount of SMEs, to integrate the access control capability into the network infrastructure can greatly simplify the IT operation and maintenance burden.

To enforce the QoE policies, apart from the policy making (as described in above ), data plane mechanisms also need to be employed. In current practice, data plane QoE mechanism mostly refers to scheduling within network devices. There are different hardware queues in a hardware interface, packets sent over the interface are put into different queues. Some queues could have higher priority for scheduling so that packets in those queues could be sent out quicker. However, such mechanism is a very general method that could not fit various requirements of modern enterprise application. The enterprise would need more sophisticated and finer granularity mechanisms to assure the bandwidth, latency, jitter etc. to be with a reasonable range.

It mainly includes following aspects: Policy Identification There could be hundreds/thousands (or even more) of policies to be enforced in an enterprise, to assure the network performance and security to meet the requirements of various kinds of services. Thus, it is necessary to make identification of these policies. The identification of the policies mainly contains the following aspects: Policy ID generation and assignment: there needs to be a comprehensive process of which entity should be responsible to assign the policy ID; and the policy ID numbering should be considered both in the context of global domain/limited domain. Policy ID security management: since the policy ID refers to sensitive information such as user group or application, the confidently should be addressed when transferred in the packets; and since different ID might imply different level of service quality, the ID integrity should also be addressed. Policy Semantics In current practice, for example the VxLAN-GBP as described in , a policy mostly refers to a user group. It is foreseeable that one policy might also need to refer to the application/service the user is using/accessing to, so that finer granularity of access control and traffic QoS assurance could be applied.

When enforcing policies in enterprise networks, various kinds of information need to be exchanged between network elements. The information could be simply categorized into two: The policies themselves: it is obvious that the one policy itself is a piece of information needs to be distributed to the policy enforcement point (e.g. switches and firewalls etc.). Traditionally, routing protocols or north-south protocols (e.g. Netconf, PCEP etc.) are utilized for flooding or configuration of such policies. Policy related meta data: since the user/device status and the administration intents are highly dynamic (for example, in the use case ABAC as described in ), the relative meta data regarding to network policies need to be updated. Considering such information update would ubiquitous and very frequent due to the mobility and complexity of the enterprise services, high efficiency of the meta data distribution should be addressed. In this sense, traditional flooding and configuration pattern might not be sufficient, new pattern such as Pub-Sub needs to be considered.

It mainly includes following aspects: Policy ID Encapsulation/Retrieving Similar as the VxLAN-GBP case as described in , the policy ID might need to be carried in band of the packets. Considering the potential comprehensive semantics of the policy described in the last section and the wide range the policy which might cover the LAN/WAN/DC segment of the enterprise networks, the policy ID might need to encapsulated into layer-3 IP packets. ID-based rules for Forwarding Actions Also similar as the VxLAN-GBP case, using IDs as match criteria in switch/firewall filtering rules is more robust than using the elements such as MAC address, IP addresses, or ports to achieve a similar effect. If there comes a new policy ID system, there needs to be relative ID-based rules in the data plane. Besides, as described , for QoE assurance scenarios, prioritization of different traffic might need more sophisticate mechanisms for enterprise applications. Some technologies utilized in operator networks such as network slicing might need to be explored.

TBD.

This document does not need IANA considerations.