SAVNET Group S. Yue Internet-Draft China Mobile Intended status: Informational X. Song Expires: 18 March 2025 ZTE Corporation C. Lin New H3C Technologies N. Geng Huawei Technologies 14 September 2024 SAVNET Use Cases draft-ys-savnet-use-cases-01 Abstract This document introduces the use case for Source Address Validation (SAV) applied in intra-domain and inter-domain telecommunication networks. It describes the typical routing implements and possible improvements for SAV in the use cases. 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 18 March 2025. Copyright Notice 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 Yue, et al. Expires 18 March 2025 [Page 1] Internet-Draft SAVNET Use Cases September 2024 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. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Mobile Transport Network . . . . . . . . . . . . . . . . . . 3 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Implementation . . . . . . . . . . . . . . . . . . . . . 3 3.3. Possible improvements for SAV . . . . . . . . . . . . . . 4 4. Fixed Transport Network . . . . . . . . . . . . . . . . . . . 4 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 4 4.3. Possible improvements for SAV . . . . . . . . . . . . . . 6 5. Data Center Network . . . . . . . . . . . . . . . . . . . . . 7 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Implementation . . . . . . . . . . . . . . . . . . . . . 7 5.3. Possible Improvements for SAV . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Source Address Validation in Intra-domain and Inter-domain Networks (SAVNET) use cases provides the typical applications at telecommunication field. Considering the network topology and technology used in these applications have big difference, the possible improvement schema for Source Address Validation (SAV) may have different considerations. This document specifically identifies the SAV use case for telecommunication networks and provides possible SAV validation location but does not suggests any specific design for SAV architecture and protocol. The SAVNET architecture introduced at [I-D.wu-savnet-inter-domain-architecture] and [I-D.li-savnet-intra-domain-architecture]. This document serves the purpose of helping those learning SAVNET applications and understand the possible influence brought by SAVNET to telecommunication scenarios and provides necessary considerations for SAV solution design. Yue, et al. Expires 18 March 2025 [Page 2] Internet-Draft SAVNET Use Cases September 2024 2. Conventions and Definitions 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. Mobile Transport Network 3.1. Description A telecom network refers to the network composed of user terminal equipment, transmission equipment, switches and telecom operators room. The communication devices and equipment interconnect to provide high flexible and dedicated services to users. The telecom network in this document is mainly related to 5G transport network, 6G transport network, etc. 3.2. Implementation The following figure shows a typical 5G Transport network architecture. ____ ____ ____ / \ / \ / \ +-------+ _/ \ _/ \ _/ \ +---------+ | User | / Access \ / Aggrega \ / Core \ |5G Mobile| |System +---+ Network +----+ Network +---+ Network +---+ System | +-------+ \_ _/ \_ _/ \_ _/ +---------+ \_____/ \_____/ \_____/ | | Option1 | IPoETH | MPLS/SRv6 | |--------------------------------------------| Option2 | IPoETH | MPLS/SRv6 | |--------------------------------------------| Option3 | IPoL2VPN | MPLS/SRv6 | |--------------------------------------------| Option4 | IPoL2VPN | MPLS/SRv6 | |--------------------------------------------| | | Figure 1: An example for mobile transport network Scenario From the implementation in NG (R)AN network there are optional connection links between CSG and Edge Node (between Access Network and Aggregation Network) which use IP or Ethernet technology. The Yue, et al. Expires 18 March 2025 [Page 3] Internet-Draft SAVNET Use Cases September 2024 more common deployment is to use MPLS/SRv6 as overlay technology to carry data packets. The LTE or 5G traffic will be transported through either a L3VPN or an L2VPN or EVPN over MPLS or SRv6 with or without segment routing. Please noted the scope of SAVNET is the validation of IPv4 and IPV6 addresses. The validation of label packets with MPLS deployments in Mobile Transport Network is out of the scope of the SAVNET. When the transport network is an SRv6 network, it may use IGP or BGP protocol extensions to support the necessary SAV information transport.. 3.3. Possible improvements for SAV As described and analyzed at the previous section, there is no need for SAVNET in MPLS network. The only location for SAVNET is in Access Network but SAVI function MAY be required and enough for source address validation. However, in the case of an AS cross-domain network for the communication between different Service Providers, the raw IPv4/IPv6 traffic is transported through EBGP technology so in order to reduce source address spoofing attack EBGP protocol SHOULD support SAVNET feature to validate the traffic accessed from other external AS domains. 4. Fixed Transport Network 4.1. Description A Fixed Transport Network refers to the network consists of optical transport, which physically connects all the fixed network nodes, may involve residential gateway, optical equipment, switch/router and broadband network gateway. The typical fixed transport network may across the wireline and wireless access, metro and backbone IP networks. 4.2. Implementation The following figure shows a typical Fixed Transport Network architecture. Yue, et al. Expires 18 March 2025 [Page 4] Internet-Draft SAVNET Use Cases September 2024 ________ ___/ \ _____ / \ / Data \_ / \__/ \ +_Center/ +------| /+----+ +----+ \_____ / |____/ | User | / | | | | \_______ / |System+--+--+BNG +----+ P +----+ \ / _ | | | | | | | | +-----+ ___/ \ +------+ | +--+-+ +----+ | +--+-+ | / \_ \ | | | | | / Backbone \ \ | +----+ +-+--+ +--+Edge|-------+ Network _/ \ | | | | | | | | | \_ _/ \ +---+ P +----+ P +--+ +----+ | \____/ \___ | | | | / \ +----+__ +----+ _____/ \_____/ \___________/ | |Backbone| | Metro Area Network |Network | |-------------------------------------|--------| | IGP | BGP | | | | Figure 2: An example for fixed transport network Scenario From the network levels perspective, it divides into residential Access Network (AN), Metro Area Network (MAN) and Backbone Network (BN). From the implementation in AN network there are optical connection links between fixed user and broadband network gateway (BNG) nodes which use IP or Ethernet technology. The BNG attached AAA server allocates ipv4/ipv6 address to fixed users the access traffic from user to fixed network will be validated at BNG. The MAN network usually implements IGP (i.e., ISIS, OSPF) routes to achieve the path connection between network nodes. Meanwhile the service traffic uses MPLS/VPN with/without segment routing technology as traffic overlay. The BN network usually implements BGP (i.e., eBGP) to achieve inter- domain network path connection. Yue, et al. Expires 18 March 2025 [Page 5] Internet-Draft SAVNET Use Cases September 2024 4.3. Possible improvements for SAV It's assumed that the most feasible way for packets validation is at the location closest to the traffic for filtering invalid address or mitigating source address spoofing. As described at the previous section, the traffic directed from user to network server the BNG is considered as a suitable validation entity. And for the reverse traffic directed from DC/contents server to user the most feasible way to validate external spoofing traffic is at the location of edge routers of BN network. If there is no SAV function implemented at edge routers of BN network, it's expected to implement SAV function at MAN network nodes. With the selection of the SAV validation entity and the use of SAV function to the network nodes at Fixed Transport Network, the incoming traffic from user and the external traffic from DC/content server can be validated effectively. It may use IGP or BGP protocol extension to support necessary SAV information transport. For the SAV function used at BNG, there is an optional way to achieve source validation function: For the upstream traffic (from user to server) 1. After receiving a packet from a broadband user, the BNG applies the SAV function to determine whether the source address of the packet belongs to the legitimate user and the inbound port. 2. If yes, packets are forwarded according to the specified rules. 3. If no, packets are discarded or redirected according to the specified rules. For the downstream traffic (from server to user) 1. BNG advertises the source route prefix of broadband users to the upstream routers and receives the reachable route from the upstream router. The network topology is reachable. 2. After receiving the traffic from the server, the BNG applies the SAV function to check whether the source address of the packet is valid and whether it matches the expected inbound port. 3. If yes, packets are forwarded according to the specified rules. 4. If no, packets are discarded or redirected according to the specified rules. Yue, et al. Expires 18 March 2025 [Page 6] Internet-Draft SAVNET Use Cases September 2024 The SAV policy may be different to upstream and downstream traffic. For example, the upstream traffic is mainly from valid users the SAV function is suggested to use allowlistt filtering policy like ACL; while the downstream traffic from internet or DC servers the SAV policy may apply allowlistt and blocklist filtering policy. The detailed SAV policy and function is out of the scope of this document. There is an optical way described at [I-D.cheng-savnet-intra-domain-sav-igp]. 5. Data Center Network 5.1. Description A data center network consists of routers, switches, firewalls, storage systems and servers to provide reliable network connectivity and secured data transport to satisfy applications or business demands. The network components require underlay infrastructure to support the data center hardware and software implementation. Driven by the scale of computing, the traditional network has scaled up and to satisfy large-scale requirements network virtualization is incorporated to data center to optimize network infrastructure. And network topology for data center has evolved from the traditional access-aggregation-core to the Clos-based spine-leaf network architecture. 5.2. Implementation The following figure shows an example for data center network topology. Yue, et al. Expires 18 March 2025 [Page 7] Internet-Draft SAVNET Use Cases September 2024 ___/ \ +--------------------------/ Data \ + +--------+_Center/ +---+-+ +----++ |____/ | ToF + ... + ToF | +-+---+ +--+--+ / | / ... | +-------+ +-----+-+ | Spine + ... + Spine | +++-----+ +--+----+ / \ / \ / \ ... / \ / \ / \ --------+--------+------ ----+-----------+------------- | +-----++ +---+--+ | | +-+----+ ++-----+ PODn | | | Leaf | | Leaf | | | | Leaf | ...| Leaf | | | +---+--+ +--+---+ | | +--+---+ +------+ | | \ / | | / / \ | | \ / | | / / \ | | +-----+ | | +-----+ ++----+ ++----+ | | | VIM | | | | VNF | ...| VNF | | PNF | | | +-----+ POD1 | | +-----+ +-----+ +-----+ | |_______________________| |______________________________| Figure 3: An example for fixed transport network Data center network deploys as underlay or overlay network model for specific service requirements. Underlay networks typically use Ethernet switching, VLAN, routing (e.g., OSPF, ISIS, BGP) to generate Equal-Cost Multi-Path (ECMP) routs between network nodes at the same level to improve network reliability and reduce network congestion. The packet encapsulation may perform at layer 2 or layer 3. Overlay networks may configure BGP EVPN service over VXLAN or GRE tunnels over IGP or BGP routing connections. RFC7938 introduces a method to support routing in large-scale data centers using BGP. RIFT protocol (see draft-ietf-rift-rift) is designed for spine-leaf Clos networks and naturally support large-scale data center networks. 5.3. Possible Improvements for SAV The data center security is very critical for network storage, management and data processing to protect applications, data and users. Applying security controls to data center to protect it from threats that could compromise integrity, confidentiality, authentication and availability of data or applications. The threats of spoofing traffic with invalid source address for one specific interface is in the scope of the document, other threats are out of Yue, et al. Expires 18 March 2025 [Page 8] Internet-Draft SAVNET Use Cases September 2024 the scope. If network nodes in the DC communicate with each other at layer 2, then the packet transport using MAC learning and MAC address spoofing is usually done when attacker is on the inside of the network. The MAC address spoofing mitigation is out of the scope. If network nodes communicate with each other at layer 3, the IP address spoofing attacks are usually from outside of the network. The incoming interface of Leaf or Spine nodes requires to deploy SAV methods to filtering spoofing traffic. The ToF nodes MAY require deploy SAV- similar methods to filtering the invalid traffic from other DCs. To mitigate IP source address spoofing attacks, the physical/virtual switches and routers in data center networks SHOULD have spoofing traffic filtering functions, such as ACL, uRPF-like, and SAVNET mechanisms. The routing protocols such as IGP, BGP and RIFT need extensions to support SAVNET policies for filtering invalid route prefixes and make right decisions for packets processing. 6. Security Considerations TBD. 7. IANA Considerations This document has no requests for IANA. 8. Acknowledgements TBD. 9. Informative References [I-D.cheng-savnet-intra-domain-sav-igp] Cheng, W., Li, D., Lin, C., and Yue, "Intra-domain SAVNET Support via IGP", Work in Progress, Internet-Draft, draft- cheng-savnet-intra-domain-sav-igp-02, 27 June 2024, . [I-D.li-savnet-intra-domain-architecture] Li, D., Wu, J., Qin, L., Geng, N., Chen, L., Huang, M., and F. Gao, "Intra-domain Source Address Validation (SAVNET) Architecture", Work in Progress, Internet-Draft, draft-li-savnet-intra-domain-architecture-07, 16 March 2024, . Yue, et al. Expires 18 March 2025 [Page 9] Internet-Draft SAVNET Use Cases September 2024 [I-D.wu-savnet-inter-domain-architecture] Li, D., Wu, J., Huang, M., Chen, L., Geng, N., Liu, L., and L. Qin, "Inter-domain Source Address Validation (SAVNET) Architecture", Work in Progress, Internet-Draft, draft-wu-savnet-inter-domain-architecture-11, 6 August 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Shengnan Yue China Mobile China Email: yueshengnan@chinamobile.com Xueyan Song ZTE Corporation China Email: song.xueyan2@zte.com.cn Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Nan Geng Huawei Technologies China Email: gengnan@huawei.com Yue, et al. Expires 18 March 2025 [Page 10]