Продукти, рішення, послуги для організацій
According to Gartner's insight report, traditional security solutions have problems such as slow delivery, lack of scalability, separate monitoring and management. To address these problems, pooled network and security capabilities are delivered to implement flexible service deployment, elastic scaling, and improved reliability. This is one of the trends of evolution to a unified security system based on cloud-network-edge-endpoint. Service providers should proactively build network and security service capabilities to meet differentiated network and security requirements of customers. Then enterprise users can subscribe to security services provided by service providers, including access control, intrusion prevention, malicious code prevention, web application security protection, and security audit, to meet their security requirements such as secure Internet access and secure cloud access. They can also subscribe to network services provided by service providers to meet their requirements in various scenarios, such as networking, Internet access, and cloud access. For example, site-to-cloud private lines are used to implement high-speed, low-latency, stable, and secure dedicated connections between enterprises and cloud data centers.
Service providers automatically complete security resource orchestration and service traffic diversion based on the network and security services subscribed by users. Specifically, for a certain network or security service flow, a service provider needs to divert the flow to one or more resource pools based on user subscription and resource allocation, and complete traffic diversion between orchestrated atomic capabilities in the resource pools. To support network servitization and security servitization, service providers need to use the traffic diversion capability provided by Service Function Chaining (SFC) technology.
SFC[1] generally refers to a group of Service Functions (SFs) arranged in an ordered sequence. This technology enables service flows to be processed by specified SFs during forwarding. These SFs can be firewalls, intrusion prevention systems (IPSs), and web application firewalls (WAFs).
Figure 1 shows the SFC architecture. Table 1 describes the key roles in the SFC architecture.
Figure 1 SFC architecture
Table 1 Key roles in the SFC architecture
Policy-based routing (PBR), one of the most commonly used SFC implementation technologies, implements targeted packet forwarding using static policy-based routes configured on devices hop by hop. However, this technology is closely coupled with the physical topology. With this technology, new service rollout requires complex configurations. As a result, service scalability is limited and inflexible. In addition, service-layer policies depend on underlying transport protocols. Insufficient E2E visualization makes it impossible to provide visualized OAM. SFs are independent of each other and cannot transmit metadata.
To overcome the disadvantages of PBR, the industry proposes a Network Service Header (NSH) solution[2] and implements its standardization in IETF. An NSH is a protocol packet header designed for an SFC. It carries the Service Path Identifier (SPI) and Service Index (SI) to guide packet forwarding in the SFC. Moreover, NSHs can carry different types of metadata (including metadata with a fixed or variable length) in an SFC domain to share information between SFs.
The NSH solution can solve some problems of PBR by separating the service layer from the network layer. However, it still has disadvantages. For example, it requires each SFF to maintain the forwarding status of each SFC, increasing control plane complexity. In addition, transparent NSH transport involves too many network encapsulation options, causing excessive workload and hindering deployment. As a result, different vendors need to negotiate the NSH transport protocol in commercial deployment, incurring high interoperability costs. Against this backdrop, many carriers and OTT vendors still prefer SFC deployment in PBR mode.
Segment Routing IPv6 (SRv6) is a new IP technology, which provides comprehensive network programming capabilities to better meet the requirements of new network services such as 5G and cloud. SRv6 supports explicit programming of data packet forwarding paths on the ingress, eliminating the need to maintain the per-flow forwarding status on transit nodes (SFFs). In this way, the control plane deployment is simplified. Therefore, SRv6 has become a new choice for SFC deployment.
To use SRv6 SFC, a network must support SRv6. Currently, mainstream device vendors, carriers, government, finance, and transportation sectors in China keep developing the SRv6 technology, and SRv6 has been commercially deployed on backbone networks, metropolitan area networks (MANs), and 5G transport networks. This promotes the development of SRv6 traffic diversion technologies for security resource pools.
However, promoting SRv6 SFC-based security service orchestration still faces many challenges, including:
1. Existing devices or nodes that provide security services and network service atomic capabilities (SFs) may not support SRv6. Therefore, to enable SRv6 to independently orchestrate all atomic capabilities, the SRv6 proxy mode needs to be provided for these atomic capabilities that do not support SRv6.
2. SRv6 provides end-to-end programmable source routing capabilities. If each atomic capability (SF) has an independent segment ID (SID), 128-bit SIDs of all SFs need to be orchestrated in the SRH of SRv6 packets. When a large number of SFs need to be orchestrated, the length of the SRH increases sharply, consuming a large amount of bandwidth in the wide area network (WAN). For example, for a service with four SFs to be orchestrated, at least 64 bytes are required in an SRH to store the list of SIDs of the four SFs.
3. In a cloud-based security resource pool, multiple VMs or containers are usually deployed to implement load balancing of atomic capabilities, providing atomic-level network and security capabilities. If SRv6 traffic diversion is used for each atomic capability, the protocol stack of each atomic capability needs to perform SRv6 parsing on packets, which will cause poor communication service efficiency, consume extra processing performance, and occupy service processing resources.
To address the deployment challenges, Huawei launches the SRv6-powered security resource pool solution for layered orchestration of networks and services. This solution optimizes the security service architecture, reduces bandwidth consumption, improves communication efficiency, and supports third-party capability orchestration. Figure 2 shows the SRv6-powered security resource pool solution for layered orchestration of networks and services. Services in a resource pool are orchestrated as a whole node, and different security resource pools are orchestrated through SRv6 to form an SFC. Atomic capabilities in a resource pool are orchestrated through policies (for example, PBR-based traffic diversion), and the mesh bus is used for high-speed communication between containers to form a sub-SFC. In this deployment mode, SRv6 is used to divert traffic based on resource pools, and protocol capabilities including SRv6 are required only for network services but not for security services.
Figure 2 SRv6-powered security resource pool solution for layered orchestration of networks and services
This solution also introduces the application-aware network (APN)[3] technology to support fine-grained network and service orchestration. An SID is planned for each resource pool. For network orchestration, APP IDs are used to determine SFCs and SRv6 tunnels are used to divert traffic to different resource pools. For service orchestration, APN IDs are used to identify tenant user IDs, which then are mapped to different sub-SFCs. Traffic is sent to security service containers according to the mapped sub-SFCs. In this way, integrated security service processing can be implemented.
Figure 3 SRv6+APN security service traffic diversion solution
To ensure secure traffic diversion of devices on the live network, the CPE functions as an SC to encapsulate VXLAN and GRE tunnels to divert traffic to the security resource pool, as shown in Figure 4. The security resource pool terminates the tunnels, identifies services based on VPNs or VLANs, and performs SFC processing. Then the traffic is diverted to the backbone network by the autonomous system boundary router (ASBR). This solution does not require device upgrade or reconstruction on the live network and can be quickly replicated after simple configuration adjustments, facilitating device reuse on the live network. Compared with this solution, the SRv6+APN solution can flexibly implement integrated orchestration of MAN and security services and provide SRv6-based slicing and OAM features. Therefore, the SRv6+APN solution is expected to be the next big thing.
Figure 4 Solution in which the CPE functions as an SC to encapsulate VXLAN and GRE tunnels to divert traffic to the security resource pool
Huawei security resource pool solution can also orchestrate third-party services. If a third-party security service supports SRv6, the VGW forwards a service flow to the corresponding security service through an SRv6 tunnel based on the SRv6 SFC ID. If a third-party security service does not supports SRv6, a third-party security service gateway needs to be deployed to function as an SRv6 proxy for the third-party security service. The VGW forwards a service flow to the third-party security service gateway through an SRv6 tunnel based on the SRv6 SFC ID. The third-party security service gateway then can send the service flow to the third-party security service for processing.
With SRv6-based network orchestration and PBR-based service orchestration, Huawei security resource pool solution incorporates the advantages of flexible SFC orchestration and NFV resource scheduling, implements the standard hierarchical SFC architecture[4][5], and facilitates deployment of resource pools and atomic capabilities. In particular, SRv6-powered traffic diversion can implement stateless SFC deployment and deliver various SRv6 features. This solution is ideal for resource implementation even with the evolution of technologies and the change of devices.
[1] https://datatracker.ietf.org/doc/rfc7665/
[2] https://datatracker.ietf.org/doc/rfc8300/
[3] https://datatracker.ietf.org/doc/draft-li-apn-framework/
[4] https://datatracker.ietf.org/doc/rfc8459/
[5] https://datatracker.ietf.org/doc/draft-huang-spring-sr-hsfc/
Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the official policy, position, products, and technologies of Huawei Technologies Co., Ltd. If you need to learn more about the products and technologies of Huawei Technologies Co., Ltd., please visit our website at e.huawei.com or contact us.
