Problem Statement, Use Cases, and Requirements of Hierarchical SFC with Segment Routing

Introduction Service Function Chaining (SFC) is a network service delivery and traffic processing technique that allows for the definition and execution of specific service chain routing policies, ensuring that data flows through a sequence of service functions in a predetermined order as it traverses the network. As network scales have grown, such as the decentralization of service resources and the diversification of tenants and vendors, it is difficult to administrate such a large network. A new network architecture known as Hierarchical Service Function Chaining (hSFC) has emerged. hSFC enables an organization to decompose large-scale networks into multiple administrative domains. This means that it can provide better network design, simplified control, and support for different functional groups within the network, thereby enhancing overall efficiency and management. To enhance network service security and offer a wide range of protective services to users, network operators have centrally constructed numerous security resource pools. Within these pools, various security network devices, such as firewalls, Web Application Firewalls (WAFs), Intrusion Prevention Systems (IPS), and more, are deployed to deliver diverse value-added services (i.e Service Function). According to tenants' business requirements or their geographical location the user traffic is steered into the corresponding security resource pool, after arriving which a series of services in a certain order are provided based on security protection needs, network topology, and resource usage. The packets need to continue the remaining original forwardness when finishing the processes inside the resource pool. As per , the original path information before entering security resource pool is expected to be stored somewhere, within the packets or in the gateway of resource pools, so that it can be restored later. Therefore, it is suitable to orchestrate with hSFC architecture. hSFC introduces a solution based on NSH (Network Service Header). This approach involves network configurations of each type of traffic and additional NSH header in packet headers, which is complicated and not conducive to expansive. However, in cases where SR (Segment Routing) networks are deployed, it only needs to issue the SR policy to define transmission path and update a new one to alter the path when physical topology or business requirements change. By contrast, the NSH solution may not be the preferred choice. This document describes a use case involving the deployment of multiple resource pools by network service provider. Every resource pool is designed to offer tenants a wide range of security protection services. The document also analyzes the challenges and issues associated with this use case, discussing the requirements, seeking an SR-based hSFC solution.

Terminology hSFC: Hierarchical Service Function Chaining NSH: Network Service Header PBR: Policy Based Routing SR: Segment Routing SFC: Service Function Chaining

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 when, and only when, they appear in all capitals, as shown here.

Use Cases To defend against network attacks, ensure the security of enterprise tenants' business applications against viruses, malware, and other security threats, and meet their customized security protection needs, network operators have established security resource pools in multiple regions. Typically, these security resource pools host various security network devices, including firewalls, Web Application Firewalls (WAF), Intrusion Prevention Systems (IPS), and more, to provide a variety of security-focused value-added services. In practical applications, the first step involves routing user traffic to the appropriate security resource pool based on user location, which typically utilizing SR in the existing Internet environment. Then, customized security protection services are provided to customers according to their specific requirements. For example, some tenants may require the use of a firewall followed by IPS services, while others may need to use IPS first and then utilize firewall services. After traversing through all SFs in a SFC, packets are returned to the gateway (i.e., security resource pool) and continue to be forwarded to devices outside of IDC. This necessitates hierarchical service chains to orchestrate SFs within security resource pool (lower-level sub-domain)and service nodes outside the IDC (upper-level domain) respectively and independently. SR is a novel network orchestration technology that guides packet paths by adding Segment Identifiers (Segment Routing) in the packet header. Each Segment Identifier corresponds to a node or service function within the network, creating an ordered path from source to destination, defining the packet's transmission route. SR service chain orchestration offers several advantages, including the flexibility to define and customize service chain paths based on specific application and business requirements, support for dynamic adjustment of service chain paths based on real-time application needs, and the ability to guide packets directly to the desired service functions, reducing unnecessary delays within the service chain. Furthermore, SR enables network administrators to manage service chains without altering the underlying network topology, simplifying network configuration. As a result, SR represents a user-friendly service chain orchestration method suitable for complex network environments that need to meet diverse application requirements. Given the complexity of internet architecture, the widespread deployment of SR, and the dynamic updates of security devices within a security resource pool, it is recommended to use SR-based service chaining for traffic steering within the security resource pool. This enables dynamic adjustment of service chains and reduces traffic bypass.

Problem Statement Due to the growth of network scales and the constraints of the existing orchestration method, security resource pools is facing some challenges of delivering value-added security protection services for different users. This section provides an overview of these challenges.

Dispersion Of Service Resources Due to varying geographical locations of different tenants and for the purpose of minimizing latency, facilitating network management, and maintenance, the security resource pool is physically deployed in a distributed manner.

Multi-tenant In the existing Internet environment, tenants' network service requirements have become diverse, with different tenants facing various threats and demands. In the security resource pool, On one hand, some tenants may only require basic access control functionality, in which case, tenants would only need firewall services. On the other hand, other tenants may necessitate more complex and comprehensive security services. For instance, certain tenants may require initial use of Web Application Firewall services to isolate potential malicious websites and code, followed by additional security checks using firewall services. Different tenants have different needs, and the security resource pool needs to provide tenant-level customized security protection capabilities. Additionally, the network security device needs to be differentiated between different tenants to provide them with distinct configuration.

Multi-vendor In a security resource pool, security network devices are usually provided by different vendors, they need to be orchestrated by unified external network communication. For example, in the security resource pool, firewalls are provided by Vendor A, and WAF is provided by Vendor B. If a customer subscribes to both firewall and WAF security value-added services, the traffic needs to pass through Vendor A's firewall first and then through Vendor B's WAF device. This implies that Vendor A's firewall needs to be aware of the next hop being Vendor B's WAF device, and there is an expectation for the traffic to flow directly from Vendor A's firewall device to Vendor B's WAF.

Dynamic Orchestration In a security resource pool, security network devices may encounter dynamic adjustments. For example, adding new security network devices to the pool may require existing service chains, such as NSH, to undergo state updates across multiple devices. The main issue in this situation is the presence of state (SPI, SI index tables) within the network devices. Therefore, when there are changes in business deployments, all network devices need to undergo state updates. This is unfavorable for flexible and agile deployments. In contrast, SR is friendly as it does not require the presence of specific states in the network.

Requirements [REQ-1] Tenant-level Service Orchestration Different tenants have varying security protection needs. specifically, the types and order of security protection they require are differently. Therefore, it is imperative to cater to multiple tenants and support tenant-level service chain orchestration. [REQ-2] Tenant Information Carriage As the security resource pool needs to meet service chaining at the tenant level, it is essential for the packets to support carrying tenant information. [REQ-3] Dynamic Allocation Of Service Resources (Scalability) The security resource pool is in a constant state of dynamic adjustment, and with the evolution of business needs, there may be additions or removals of certain security network devices. When there are updates to the security network devices within the resource pool, it is essential to support their dynamic orchestration into the service chain. [REQ-4] Independent Resource Pool Orchestration Service functions in different security resource pools support different protocols (i.e., some security network devices within certain resource pools do not support SR), and their suitable methods for service chaining may also vary. Achieving unified orchestration is challenging. Therefore, it is necessary for security resource pools to support independent orchestration, without interfering with each other. [REQ-5] Reliability Of Service Function During service chain orchestration, it is necessary to support the retrieval of device information, including device operational status, identification details, etc. In the event of network equipment issues, bypassing the problematic equipment to avoid traffic disruption should be enabled.

Security Considerations TBD.

IANA Considerations This document has no IANA actions.