Network Working Group D. Li Internet-Draft J. Wu Intended status: Standards Track Tsinghua University Expires: 13 September 2023 M. Huang Huawei L. Chen Zhongguancun Laboratory N. Geng Huawei L. Qin Tsinghua University F. Gao Zhongguancun Laboratory 12 March 2023 Intra-domain Source Address Validation (SAVNET) Architecture draft-li-savnet-intra-domain-architecture-01 Abstract Intra-domain source address validation (SAV) plays an important role in defending against source address spoofing attacks in intra-domain networks. This document proposes an intra-domain source address validation (intra-domain SAVNET) architecture. Under the architecture, a router can automatically generate accurate SAV rules based on the SAV-related information from multiple information sources. This document does not specify protocols or protocol extensions, instead focusing on architectural components and their functionalities in an intra-domain SAVNET deployment. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 8174 [RFC8174]. 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/. Li, et al. Expires 13 September 2023 [Page 1] Internet-Draft Intra-domain SAVNET Architecture March 2023 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 13 September 2023. Copyright Notice Copyright (c) 2023 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Intra-domain SAVNET Architecture . . . . . . . . . . . . . . 5 4.1. SAV Information Base Manager . . . . . . . . . . . . . . 6 4.2. RPDP and RPDP Speaker . . . . . . . . . . . . . . . . . . 7 5. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Source address validation (SAV) is important for mitigating source address spoofing and contributing to the Internet security. Source Address Validation Architecture (SAVA) [RFC5210] divides SAV into three checking levels, i.e., access-network SAV, intra-domain SAV, and inter-domain SAV. When an access network does not deploy SAV (such as SAVI [RFC7039][RFC7513], Cable Source Verify [cable-verify], and IP Source Guard [IPSG]), intra-domain SAV helps block spoofed packets as close to the source as possible. Li, et al. Expires 13 September 2023 [Page 2] Internet-Draft Intra-domain SAVNET Architecture March 2023 There are some intra-domain SAV mechanisms available. However, existing intra-domain SAV mechanisms have the problems of inaccurate validation under asymmetric routing and high operational overhead in dynamic networks [draft-li-savnet-intra-domain-problem-statement]. To solve the problems above, this document proposes an intra-domain source address validation (intra-domain SAVNET) architecture. Under the architecture, routers can collaborate to discover real incoming interfaces of source prefixes adaptive to routing status, and the packets from all directions can be validated, which yields improvements on source address protection. This document focuses on the high-level architecture designs and does not specify protocols or protocol extensions. 2. Terminology SAV Rule: The rule that indicates the valid incoming interfaces for a specific source prefix or that indicates the valid source prefixes for a specific interface. SAV Table: The table or data structure that implements the SAV rules and is used for source address validation in the data plane. Improper Block: The validation results that the packets with legitimate source addresses are blocked improperly due to inaccurate SAV rules. Improper Permit: The validation results that the packets with spoofed source addresses are permitted improperly due to inaccurate SAV rules. SIB: SAV information base that is for storing SAV-related information collected from different information sources. SMP: SIB management protocol that represents any protocols for managing data in SIB. RPDP: Real path discovering protocol, generally referring to the extension of existing routing protocols. The RPDP messages can explicitly or implicitly indicate the real incoming interfaces of some specified source prefixes. 3. Design Goals The intra-domain SAVNET architecture is to enhance the intra-domain SAV and aims to achieve the following goals: Li, et al. Expires 13 September 2023 [Page 3] Internet-Draft Intra-domain SAVNET Architecture March 2023 * Accurate validation. The real incoming interfaces of source prefixes need to be completely learned, and improper block can be avoided. By trying to exclude non-real incoming interfaces from the valid interface group, improper permit can be reduced. * Low operational overhead. The routers after initial configurations can adapt to dynamic routing changes automatically, so that the operational overhead can be controlled. * Working in partial deployment. Routers need to do SAV for both external packets (from subnets or the Internet) and internal packets (forwarded by other routers). On the one hand, edge (or border) routers take SAV for external packets including those from both the subnets and the Internet. On the other hand, edge routers and non-edge routers take SAV for internal packets, which is necessary in partial deployment cases. Under partial deployment, edge routers may not be able to block all the spoofed external packets. SAV for internal packets is to filter the malicious packets mixed in internal packets. To achieve the goal of accurate validation, a router cannot generate SAV rules based on only local RIB/FIB because asymmetric routing exists, and purely relying on manual SAV rule configurations for guaranteeing accurate validation is not practical. The key challenge is how to make a router automatically discover real incoming interfaces of source prefixes of both external and internal packets. Consider that the real incoming interfaces are determined by the forwarding rules of other routers in the network and cannot be entirely obtained locally. To address the key challenge, the intra- domain architecture includes a real path discovery protocol (RPDP) by extending existing routing protocols. Routers will propagate SAV- related data by sending RPDP messages adaptive to forwarding rules. These messages will be received by other routers. By combining the information from manual configurations, RIB/FIB, and protocol messages, accurate SAV rules for both external and internal packets can be generated. Other design goals, such as low data plane overhead and easy implementation, are also important, but out of the scope of this document. They should be considered in specific protocols or protocol extensions of SAVNET. Li, et al. Expires 13 September 2023 [Page 4] Internet-Draft Intra-domain SAVNET Architecture March 2023 4. Intra-domain SAVNET Architecture The intra-domain SAVNET architecture is depicted from the perspective of a router. Figure 1 shows the architecture which consists of a few components. Among these components, the three of SAV Information Base (SIB) manager, RPDP speaker, and SAV table are specialized for SAV. The other components are existing ones but are required for SAV rule generation. +------------------------------------------+ | Other Protocol Speakers | +------------------------------------------+ /\ | Protocol Messages +-----------------------------------------------------+ | Router | | | \/ | | +-------------------------------------------------+ | | | Routing +------------------------+ | | | | Protocol | RPDP Speaker | | | | | Speaker +------------------------+ | | | +-------------------------------------------------+ | | |Routing /\Routing |SAV | | |Information |Table |Information | | |Dissemination | |Dissemination | | |Messages | |Messages | | \/ | \/ | | +--------------------+ +----------------------+ | | | | |+--------------------+| | | | Routing | ||SAV Information Base|| | | | Information |-->|+--------------------+| | | | Base | | SAV Information Base | | | | | | Manager | | | +--------------------+ +----------------------+ | | |SAV Rules | | \/ | | +-----------+ | | | SAV Table | | | +-----------+ | +-----------------------------------------------------+ /\ Manual Configurations | +----------------------+ | CLI, YANG, SMP, etc. | +----------------------+ Figure 1: The intra-domain SAVNET Architecture Li, et al. Expires 13 September 2023 [Page 5] Internet-Draft Intra-domain SAVNET Architecture March 2023 4.1. SAV Information Base Manager SIB manager is the core component for SAV rule generation in the architecture. The component collects SAV-related information from multiple information sources, stores the information in SIB after consolidation, and outputs SAV rules based on the stored information. SAV rules indicate the valid incoming interfaces of source prefixes, which can be represented by pairs. As described previously, collecting SAV-related information purely from local routing information and manual configuration is not enough or practical for learning accurate pairs. The protocol called RPDP in the document is designed as the third information source which provides accurate SAV information. Therefore, in the architecture, there are total of three information sources, which are listed as follows: * Manual Configuration: The routers should support SAV-related configurations. The configurations may be from CLI, YANG, SIB management protocol (SMP), etc. SMP mentioned herein represents any protocols designed for managing data in SIB. * Routing Information Base: RIB stores routing information learned from routing protocols. It has been used in some existing SAV mechanisms. * RPDP Messages: Routers will send RPDP messages according to local forwarding rules. The real incoming interfaces of source prefixes can be learned from the received messages. Although there are multiple information sources, one can choose some of them (e.g., RIB and RPDP speaker) for SAV instead of using all of them. When more than one information sources are used, data conflicts may exist. To address the issue, priorities can be set to the sources. For the items with data conflicts, the items from the source of higher priority will be preferred. For the items without data conflicts, a union of the items will be taken. For example, suppose that manual configuration has the highest priority. When the information from RIB indicates that Interface 1 is the valid incoming interface of source prefix P1, the operators can manually configure Interface 1 as the invalid interface of P1. By consolidating the information from different sources, SAV manager will get the pairs of for all prefixes, which are stored in SAV information base. Figure 2 illustrates SAV information base. In the figure, each source prefix (including the default prefix, i.e., 0.0.0.0) has one or more valid incoming interfaces. The information sources for a pair of are also Li, et al. Expires 13 September 2023 [Page 6] Internet-Draft Intra-domain SAVNET Architecture March 2023 recorded. For example, P1 has two incoming interfaces of Interface 1 and Interface 3. Any other interfaces except Interface 1 and 3 will be considered invalid for P1. In the example, Interface 3 for P1 is discovered by only RPDP, which may appear in asymmetric routing cases. An SAV table can be generated based on SAV information base. The SAV rules in the table will be installed into the data plane for validating the packets from all directions. The working modes and usage suggestions of SAV table can be found in [draft-huang-savnet-sav-table]. +----------------------------------------------------------+ | Source Prefix | Incoming Interface | Information Sources | +---------------+--------------------+---------------------+ | P1 | Interface 1 | b,c | | P1 | Interface 3 | b | | P2 | Interface 2 | b,c | | P3 | Interface 4 | a | | ... | ... | ... | | default | Interface 4 | a | +----------------------------------------------------------+ * a: Manual Config, b: RIB, c: RPDP Figure 2: An illustration of SAV information base 4.2. RPDP and RPDP Speaker The RPDP is for automatically discovering real incoming interfaces of source prefixes. Particularly, the RPDP needs to extend existing routing protocols. The RPDP speaker is responsible for dealing with message interactions of the RPDP, and it naturally resides in the routing protocol speaker. The RPDP messages are carried by newly defined TLVs or messages of routing protocols. Through the RPDP speaker, routers can send RPDP messages explicitly or implicitly indicating the real incoming interfaces of some specified source prefixes. A router receiving RPDP messages can resolve the SAV-related information for rule generation. Thus, there exists cooperation between routers. The followings are some kinds of SAV-related information that can be propagated by RPDP: * Source prefixes with a configured tag. A router can construct a message containing some source prefixes (e.g., the prefixes matching a routing policy) as well as a configured tag. The routers whose interfaces are configured the same tag value, will receive the tagged source prefixes and will consider the interfaces with the same tag value as the real incoming interfaces Li, et al. Expires 13 September 2023 [Page 7] Internet-Draft Intra-domain SAVNET Architecture March 2023 of these source prefixes. Note that, some initial manual configurations are needed such as tag configuration and prefix matching policy configuration. After the initial configurations, the routers can adapt to prefix changes automatically. * Source prefixes which are propagated through real forwarding paths. A router can construct a message containing some source prefixes and one of the locally reachable destination prefixes. The message will be sent to the nexthop through which the destination prefix is reachable according to the local forwarding rules. The routers receiving the message from an interface will bind the interface with the source prefixes. Then, the message will be sent out by looking up the local forwarding rules of the destination prefix. A router may have lots of locally reachable destination prefixes and needs to send messages for each of the destination prefixes so that all the real incoming interfaces can be discovered. To reduce the communication overhead, a message can contain multiple destination prefixes who have the same nexthop. Note that, any factors that affect forwarding should be considered during the message propagation. * Forwarding information. A router can advertise the local forwarding information (e.g., route redirection) that may result in asymmetric routing. Then, other routers will conduct path computations and then get the real forwarding paths of source prefixes. In the architecture, the RPDP speaker will get routing table from the RIB and policy routing information from the policy-based routing. These kinds of information will be useful for the RPDP speaker constructing and sending RPDP messages. After receiving RPDP messages, the speaker will disseminate SAV information to the SIB manager component. The RPDP speaker should sense the adaptiveness of local source prefixes, forwarding rules, and SAV-related configurations (e.g., tags), etc. The adaptiveness should be notified to related routers through RPDP messages in time. 5. Partial Deployment Since an intra-domain network mostly has one administration, it is possible to deploy SAVNET on all routers. Under full deployment, only edge routers need to enable SAV for validating external packets. However, partial deployment may still exist due to phased deployment or the limitations coming from multi-vendor supplement. In such cases, the SAV for internal packets are needed, which is supported by the intra-domain SAVNET architecture. Li, et al. Expires 13 September 2023 [Page 8] Internet-Draft Intra-domain SAVNET Architecture March 2023 There are another kind of cases where the SAV for internal packets are necessary. Sometimes, the software of some edge routers has been upgraded for supporting SAVNET, but these routers are not able to do SAV due to the limited data plane capability. In such cases, these edges routers can still run SAVNET protocols to help other routers accurately validating external and internal packets. The architecture does not require to be deployed in the whole network like an AS. It also works when an area of the network supports the architecture. A more detailed analysis on partial deployment may be provided in the future version of the document. 6. Security Considerations The security considerations should be provided in the protocol extension documents. 7. Privacy Considerations An intra-domain network is mostly operated by a single organization or company, so the architecture does not import privacy issues in most cases. There should be an analysis on privacy in the protocol extension documents. 8. IANA Considerations This document has no IANA requirements. 9. References 9.1. Normative References [draft-li-savnet-intra-domain-problem-statement] Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement, and Requirements", 15 December 2022. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [cable-verify] Cisco, "Cable Source-Verify and IP Address Security", 2021, . Li, et al. Expires 13 September 2023 [Page 9] Internet-Draft Intra-domain SAVNET Architecture March 2023 [draft-huang-savnet-sav-table] Huang, M., Zhou, T., Geng, N., Li, D., Chen, L., and J. Wu, "Source Address Validation Table Abstraction and Application", 24 October 2022. [IPSG] Cisco, "Configuring DHCP Features and IP Source Guard", 2016, . [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", RFC 5210, DOI 10.17487/RFC5210, June 2008, . [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, . [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, . Authors' Addresses Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Jianping Wu Tsinghua University Beijing China Email: jianping@cernet.edu.cn Mingqing Huang Huawei Beijing China Email: huangmingqing@huawei.com Li, et al. Expires 13 September 2023 [Page 10] Internet-Draft Intra-domain SAVNET Architecture March 2023 Li Chen Zhongguancun Laboratory Beijing China Email: lichen@zgclab.edu.cn Nan Geng Huawei Beijing China Email: gengnan@huawei.com Lancheng Qin Tsinghua University Beijing China Email: qlc19@mails.tsinghua.edu.cn Fang Gao Zhongguancun Laboratory Beijing China Email: gaofang@zgclab.edu.cn Li, et al. Expires 13 September 2023 [Page 11]