| Internet-Draft | SR hSFC Usecases | March 2024 |
| Ni, et al. | Expires 3 September 2024 | [Page] |
Hierarchical Service Function Chaining (hSFC) is a network service chaining method that utilizes a hierarchical structure to efficiently organize and manage service function chains, enhancing network performance and scalability. This document primarily describes the use case of hSFC, which is the security resource pool. It outlines the associated problem statement and requirements for the security resource pool. The document aims to assist in identifying candidate solution architectures and solutions.¶
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 3 September 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
Service Function Chaining (SFC) [RFC7665] 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) [RFC8459] 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 [RFC8459], 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.¶
hSFC: Hierarchical Service Function Chaining¶
NSH: Network Service Header¶
PBR: Policy Based Routing¶
SR: Segment Routing¶
SFC: Service Function Chaining¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
[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.¶
This document has no IANA actions.¶