SAVNET Group S. Yue Internet-Draft China Mobile Intended status: Informational X. Song Expires: 3 September 2024 ZTE Corporation C. Lin New H3C Technologies N. Geng Huawei Technologies 4 March 2024 SAVNET Use Cases draft-ys-savnet-use-cases-00 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 3 September 2024. 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 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. Yue, et al. Expires 3 September 2024 [Page 1] Internet-Draft SAVNET Use Cases March 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 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. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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. 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. Yue, et al. Expires 3 September 2024 [Page 2] Internet-Draft SAVNET Use Cases March 2024 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/VPN/SR | |--------------------------------------------| Option2 | IPoETH | MPLS/VPN/SR | |--------------------------------------------| Option3 | IPoL2VPN | MPLS/VPN/SR | |--------------------------------------------| Option4 | IPoL2VPN | MPLS/VPN/SR | |--------------------------------------------| | | 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 more common deployment is to use MPLS/VPN 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 IP with or without segment routing. Yue, et al. Expires 3 September 2024 [Page 3] Internet-Draft SAVNET Use Cases March 2024 Please noted the scope of SAVNET is the validation of IPv4 and IPV6 addresses. The validation of label packets with MPLS/VPN deployments in Mobile Transport Network is out of the scope of the SAVNET. 3.3. Possible improvements for SAV As described and analyzed at the previous section, there is no need for SAVNET in MPLS/VPN 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 3 September 2024 [Page 4] Internet-Draft SAVNET Use Cases March 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 3 September 2024 [Page 5] Internet-Draft SAVNET Use Cases March 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. 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. Yue, et al. Expires 3 September 2024 [Page 6] Internet-Draft SAVNET Use Cases March 2024 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. Security Considerations TBD. 6. IANA Considerations This document has no requests for IANA. 7. Acknowledgements TBD. 8. Informative References [I-D.cheng-savnet-intra-domain-sav-igp] Cheng, W., Li, D., Lin, C., and Yue, "Intra-domain SAV Support via IGP", Work in Progress, Internet-Draft, draft- cheng-savnet-intra-domain-sav-igp-01, 25 February 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-06, 21 January 2024, . [I-D.wu-savnet-inter-domain-architecture] Wu, J., Li, D., 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-06, 5 February 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Yue, et al. Expires 3 September 2024 [Page 7] Internet-Draft SAVNET Use Cases March 2024 [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 3 September 2024 [Page 8]