Internet DRAFT - draft-liu-enterprise-network-policies
draft-liu-enterprise-network-policies
Network Working Group B. Liu
Internet-Draft Q. Gao
Intended status: Informational Huawei Technologies
Expires: 5 September 2024 Y. Liu
China Unicom
4 March 2024
Scenarios and Potential Future Work of Enterprise Network Policies
draft-liu-enterprise-network-policies-00
Abstract
This document describes several typical scenarios of utilizing
network policies against enterprise networks, and discusses some
existing work and the limitations. Lastly, this document proposes
several aspects of potential future work that might led to a
formation of policy plane for enterprise networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al. Expires 5 September 2024 [Page 1]
Internet-Draft enterprise network policies March 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Common Scenarios of Enterprise Network Policies . . . . . . . 3
3.1. Access Control . . . . . . . . . . . . . . . . . . . . . 3
3.2. Service QoE Assurance . . . . . . . . . . . . . . . . . . 4
4. Analysis of Existing Work . . . . . . . . . . . . . . . . . . 5
4.1. Group Based Policy (GBP) . . . . . . . . . . . . . . . . 5
4.2. Identity and Access Management (IAM) . . . . . . . . . . 6
4.3. QoE for Enterprise Networks . . . . . . . . . . . . . . . 7
5. Potential Future Work . . . . . . . . . . . . . . . . . . . . 7
5.1. Policy Management . . . . . . . . . . . . . . . . . . . . 7
5.2. Information Distribution . . . . . . . . . . . . . . . . 8
5.3. Data Plane Enforcement . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
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
Liu, et al. Expires 5 September 2024 [Page 2]
Internet-Draft enterprise network policies March 2024
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.
2. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Common Scenarios of Enterprise Network Policies
3.1. Access Control
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.
Liu, et al. Expires 5 September 2024 [Page 3]
Internet-Draft enterprise network policies March 2024
* 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.
3.2. Service QoE Assurance
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.
Liu, et al. Expires 5 September 2024 [Page 4]
Internet-Draft enterprise network policies March 2024
* 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.
4. Analysis of Existing Work
4.1. Group Based Policy (GBP)
GBP is firstly defined by OpenStack [GroupBasedPolicy] , 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 Section 3 , 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 [I-D.smith-vxlan-group-policy] tacking this issue and trying to
standardize the approach.
Liu, et al. Expires 5 September 2024 [Page 5]
Internet-Draft enterprise network policies March 2024
4.2. Identity and Access Management (IAM)
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 Section 3.1 , 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.
Liu, et al. Expires 5 September 2024 [Page 6]
Internet-Draft enterprise network policies March 2024
4.3. QoE for Enterprise Networks
To enforce the QoE policies, apart from the policy making (as
described in above Section 3.1 ), 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.
5. Potential Future Work
5.1. Policy Management
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
Liu, et al. Expires 5 September 2024 [Page 7]
Internet-Draft enterprise network policies March 2024
In current practice, for example the VxLAN-GBP as described in
Section 4.1 , 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.
5.2. Information Distribution
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:
1. 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.
2. 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 Section 3.1 ), 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.
5.3. Data Plane Enforcement
It mainly includes following aspects:
* Policy ID Encapsulation/Retrieving
Similar as the VxLAN-GBP case as described in Section 4.1 , 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
Liu, et al. Expires 5 September 2024 [Page 8]
Internet-Draft enterprise network policies March 2024
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 Section 4.3 , 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.
6. Security Considerations
TBD.
7. IANA Considerations
This document does not need IANA considerations.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[GroupBasedPolicy]
"Group based policy", , 2015,
<https://wiki.openstack.org/wiki/GroupBasedPolicy>.
[I-D.smith-vxlan-group-policy]
Smith, M. and L. Kreeger, "VXLAN Group Policy Option",
Work in Progress, Internet-Draft, draft-smith-vxlan-group-
policy-05, 22 October 2018,
<https://datatracker.ietf.org/doc/html/draft-smith-vxlan-
group-policy-05>.
Liu, et al. Expires 5 September 2024 [Page 9]
Internet-Draft enterprise network policies March 2024
Authors' Addresses
Bing Liu
Huawei Technologies
Q11, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing
100095
P.R. China
Email: leo.liubing@huawei.com
Qiangzhou Gao
Huawei Technologies
Q11, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing
100095
P.R. China
Email: gaoqiangzhou@huawei.com
Ying Liu
China Unicom
Beijing
China
Email: liuy619@chinaunicom.cn
Liu, et al. Expires 5 September 2024 [Page 10]
