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, 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). The resource pool, managed as an independent domain, requires directing user traffic into the security resource pool and performing orchestration within the pool, which is suitable for the hSFC architecture. A security resource pool can select one or more resource pools based on the tenant's location, network topology, and resource usage to provide services to tenants. hSFC introduces a solution based on NSH (Network Service Header). However, this approach involves network configurations and additional NSH header in packet headers. In cases where SR (Segment Routing) networks are deployed, 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. 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. This necessitates orchestrating service chains for the overall security resource pool and the internal security network devices. 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 customized 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 This section provides an overview of the challenges that security resource pools face when attempting to deliver value-added security protection services for different uesrs.

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 differentiate 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] Reliablity 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.