SAVNET W. Cheng Internet-Draft China Mobile Intended status: Standards Track C. Lin Expires: December 27, 2024 New H3C Technologies S. Yue China Mobile June 27, 2024 Intra-domain SAV Support via BGP draft-cheng-savnet-intra-domain-sav-bgp-01 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 27, 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 (http://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 Simplified BSD License text as described in Cheng, et al. Expires December 27, 2024 [Page 1] Internet-Draft Intra-domain SAV Support via BGP June 2024 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes a method for publishing source prefixes via the BGP protocol, iterating through the SAV table entries based on intra-domain next hop SAV rules. The generation of intra-domain next hop SAV rules is implemented by the intra-domain IGP protocol, and the BGP protocol inherits the source interface list from its next hop SAV rules to generate the SAV rule table for source prefixes. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 3. Solution.......................................................4 3.1. Overview..................................................4 3.2. Intra-domain SAVNET.......................................6 3.3. Procedure.................................................8 3.4. Multi-Homed Scenarios.....................................9 3.5. BGP Source Prefix Filtering..............................10 4. Example.......................................................10 5. Deployment Considerations.....................................11 5.1. Intra-domain SAV Support via IGP and BGP.................11 6. IANA Considerations...........................................12 7. Security Considerations.......................................12 8. References....................................................12 8.1. Normative References.....................................12 8.2. Informative References...................................13 Acknowledgments..................................................13 Authors' Addresses...............................................13 Cheng, et al. Expires December 27, 2024 [Page 2] Internet-Draft Intra-domain SAV Support via BGP June 2024 1. Introduction As shown in Figure 1, the existing network has the following scenario: within the intra-domain network, topology information is disseminated via the IGP protocol, while prefix information is distributed via iBGP neighbors. All iBGP nodes establish iBGP neighbor relationships with Route Reflectors (RRs) and exchange source prefix information. The IGP protocol contains network topology information but lacks source prefix information, while the BGP protocol holds source prefix information but does not include network topology information. In this scenario, it is necessary to combine the network topology information from IGP with the source prefix information from the BGP protocol in order to compute the source prefix's associated source port information and generate SAV rules. +---------------------------------------------------------+ | AS | | | | iBGP =========== RR =========== iBGP | | +---------+ ( ) +---------+ | | |iBGP Node|---( IGP Network )-----|iBGP Node| | | +---------+ ( ) +---------+ | +---------------------------------------------------------+ Figure 1: The case of the SAVNET Procedure The scenario described in [draft-cheng-savnet-intra-domain-sav-IGP- 00] and [I-D.lin-Intra-domain-savnet-method] involves the publication of SAV source prefix by the IGP protocol, and the generation of SAV rules based on the connectivity calculation using the IGP's topology information. However, for the scenario described in this document, where the source prefix information is published by the BGP protocol, it is unable to generate the required SAV rules. This document describes how to generate SAV rules using the topology information from the IGP protocol and the source prefix information from the BGP protocol in this network scenario. 2. Terminology The following terminologies are used in this document. Cheng, et al. Expires December 27, 2024 [Page 3] Internet-Draft Intra-domain SAV Support via BGP June 2024 SAV Rule: The rule that indicates the source validity of a specific IP address or an IP prefix. SAV Table: The table or data structure that implements the SAV rules and is used for source address validation in the data plane. IGP: Interior Gateway Protocol. BGP: Border Gateway Protocol. Source prefix: The source prefixes are used to validate source addresses in the data plane. 3. Solution 3.1. Overview As shown in Figure , [draft-ietf-savnet-intra-domain-architecture- 00] describes SAV filtering on three types of interfaces: interfaces on host-facing routers, such as interface 1 on Router C as shown in the figure; interfaces on customer-facing routers, such as interface 1 on Router A and interface 1 on Router B as shown in the figure; and interfaces on AS border routers, such as interface 2 on Router D and interface 2 on Router E when facing another AS. For the first two types of interfaces, SAV filtering is primarily carried out using an allow-list. For the third type of interface, filtering is primarily implemented using a block-list. This document also describes SAV filtering on the interfaces of routers within the domain, such as Interface 1 of Router D and Interface 1 of Router E, as depicted in the diagram. Such interfaces employ allow-list based SAV filtering, with the computation process outlined in Section 3.3. The specific details about allow-list and block-list are detailed below. +----------------------------------+ | Other ASes | +----------------------------------+ | | +------------------|----------------------------|--------------+ | Intra-domain | | | | iBGP | | | | |2 |2 | | +----+#+---+ +----+#+---+ | | | Router D | | Router E | | | +----+#+---+ +----+#+---+ | Cheng, et al. Expires December 27, 2024 [Page 4] Internet-Draft Intra-domain SAV Support via BGP June 2024 | |1 |1 | | | | | | | | | | +----+#+--------------------------+#+----+ | | | Other intra-domain routers | | | +-+#+---+#+-----------------------+#+----+ | | / \ | | | / \ | | | / \ | | | +----+#+---+ +----+#+---+ +----+#+---+ | | | Router A | | Router B | | Router C | | | +---+#+----+ +------+#+-+ +----+#+---+ | | \1 /1 |1 | +------------\------------/---------------------|--------------+ \ / | +--------------+ +--------------+ | Customer | | Host | | Network | | Network | +--------------+ +--------------+ Figure 2: Overview of intra-domain SAVNET architecture The term allow-list means that if a packet received from a specified interface has a source address found in the interface's allow-list, then the packet should be permitted to pass through. For example, for an allow-list entry (P1, A-1), if a packet received from interface A-1 has a source address within the range of P1, then the packet will be allowed to pass through. Otherwise, the packet will be discarded. The term block-list means that if a packet received from a specified interface has a source address found in the interface's block-list, then the packet must be discarded. Otherwise, the packet will be allowed to pass through. For the host-facing router interfaces, the allow-list can be generated for directly connected host segments, as shown in Figure 2. If the interface 1 network segment address of Router C is P, the allow-list (P, C-1) can be generated for Router C's interface 1. For the ports of routers facing the customers, as shown in Figure 2, if the interface 1 network segment address of Router A is P1, and the interface 1 network segment address of Router B is P2, the allow-lists (P1, A-1) and (P2, A-1) can be generated for Router A's interface 1, and the allow-lists (P1, B-1) and (P2, B-1) can be generated for Router B's interface 1. Cheng, et al. Expires December 27, 2024 [Page 5] Internet-Draft Intra-domain SAV Support via BGP June 2024 For the router interfaces facing the customers, as shown in Figure 2, where Router A's interface 1 belongs to network segment address P1 and Router B's interface 1 belongs to network segment address P2, the allow-lists (P1, A-1) and (P2, A-1) can be generated for Router A's interface 1, and the allow-lists (P1, B-1) and (P2, B-1) can be generated for Router B's interface 1. For the inter-domain router interfaces, as depicted in Figure 4, where Router D's interface 1 and Router E's interface 1 are involved, the calculation process described in section 4.3 can be used to generate the allow-lists for Router D's interface 1 and Router E's interface 1. For the interface facing another AS, as shown in Figure 2, such as Router D's interface 2 and Router E's interface 2, this scenario typically involves using block-lists for SAV filtering. The generation of block-lists on the edge interfaces connecting to external domains can be achieved by generating block-list entries on the upper interface when learning routes from the lower interface. For example, if Router D learns the prefix P on interface 1, then a block-list entry (P, D-2) can be generated on interface 2. 3.2. Intra-domain SAVNET This section introduces a new method for computing and generating SAV rules based on BGP source prefix and IGP topology information in an intra-domain scenario. This method relies on two fundamental pieces of information: the source prefix information and reachability information. The source prefix information can be transmitted through static configuration or the BGP protocol. This document addresses the scenario where source prefix information is transmitted via the BGP protocol. The source prefix information consists of the source prefix and the next-hop information for the prefix publication. The IGP's topology information includes the connectivity details between nodes and the IGP prefix information published by each node. As depicted in Figure 3, source prefix information is disseminated via the BGP protocol, where Router C advertises the source prefix Prefix1 with a next hop of Router 2, Router D advertises the source prefix Prefix2 with a next hop of Router 3, and Router E advertises the source prefix Prefix3 with a next hop of Router 4. Router B, serving as the BGP Route Reflector, is responsible for collecting and reflecting all BGP source prefix information. Cheng, et al. Expires December 27, 2024 [Page 6] Internet-Draft Intra-domain SAV Support via BGP June 2024 Based on the IGP's topology information, the interface list corresponding to the IGP prefix can be calculated. The specific calculation process can be found in [draft-cheng-savnet-intra- domain-sav-BGP-00]. The first-level NextHop SAV rule table is generated based on this information in the form of (IGP-Prefix, if). The calculation of the next-hop SAV rule is not limited to IGP and can involve other new extended protocols not described in this document. Subsequently, using the source prefix information distributed via the iBGP protocol, a match is made against the first-level SAV rule table based on the source prefix information. Once a match is found, the interface list "if" is inherited to produce the second-level SAV rule table (BGP-Prefix, if). This document relies on the generation of SAV rules based on the next hop derived from the IGP protocol. The relationships of the generated SAV rule table are illustrated in Figure 4. +---------------------------------------------------------+ | AS | | iBGP Router1 | | SAV Rule: +--------3-+ | | (Prefix1, A-1) | Router A | | | (Prefix2, A-1) +1--------2+ | | (Prefix3, A-2) /\ /\ | | / \ | | / \ | | / \ | / \ | RR +----------+ +----------+ | |iBGP Router5| Router B | | Router E | iBGP Router6 | | +1--------2+ +---------1+ | | /\ /\ /\ | | / \ \ | | / \ \ | | +----------+ +----------+ +----------+ | | | Router C | | Router D | | Router F | | | +----------+ +----------+ +----------+ | | | | | | | iBGP Router2 iBGP Router3 iBGP Router4 | | Prefix1 Prefix2 Prefix3 | +---------------------------------------------------------+ Figure 3: Example 1 of Topology Calculation Cheng, et al. Expires December 27, 2024 [Page 7] Internet-Draft Intra-domain SAV Support via BGP June 2024 This approach enables automatic adjustment of SAV table entries based on topological changes, thereby achieving secure protection for source addresses within the domain. +----------+ +----------+ | BGP Route| | IGP LSDB | +----------+ +----------+ | | | | | V | V +------------+ | NextHop <- - - - -> |NextHop SAV | | | +------------+ | | V V Source NextHop Prefix If | V +------------+ | BGP SAV | +------------+ Figure 4: The calculation process of BGP SAV table 3.3. Procedure The calculation process for intra-domain SAV rules based on BGP is as follows: Step 1: Perform calculation based on the LSDB of the IGP protocol and generate first-level SAV rules using the prefix information published by the IGP nodes. The generated SAV rule takes the form: (IGP-Prefix, if). This also forms the next-hop SAV table required for BGP. Step 2: Iterate through all source prefix information distributed by the BGP protocol. For each source prefix, match it with the corresponding next-hop information of the publisher. Then, search and match this next-hop address in the SAV rules generated in Step 1. Obtain and utilize the inherited interface list from the first- level SAV rules to generate second-level SAV rules. The generated rules take the form: (BGP-Prefix, if). Cheng, et al. Expires December 27, 2024 [Page 8] Internet-Draft Intra-domain SAV Support via BGP June 2024 Step 3: If there are changes in the topological information of the IGP protocol, repeat the calculation in Step 1. If there are changes in the SAV rules generated in Step 1, the BGP protocol refreshes the (BGP-Prefix, if) rule table based on the next-hop associated SAV table, thus skipping Step 2. Step 4: If there are changes in the source prefix information distributed by the BGP protocol, skip Step 1 and proceed with the calculation according to Step 2, refreshing the rule list generated by BGP. 3.4. Multi-Homed Scenarios In the multi-homed scenario depicted in Figure 5, the prefix 10.0.0.0/16 is accessed via nodes D and E, with the subnet 10.0.1.0/24 being accessed via node D, and 10.0.0.0/24 being accessed via node E. Through IGP connectivity calculation, the SAV table entries derived on node A are: (10.0.1.0/24, A-1), (10.0.0.0/24, A-2). +---------------------------------------------------+ | iBGP 11.11.11.11 AS | | Node A SAV Rule: +--------+ | | (10.0.1.0/24, A-1) | Node A | | | (10.0.0.0/24, A-2) +1------2+ | | / \ | | / \ | | / \ | | +--------+ +--------+ | | | Node B | | Node D | | | +-+------+ +---+----+ | | | | | | | | | | | | | | +----+2--+ +---+2---+ | | | Node C | | Node E | | | +----+1--+ +---+1---+ | | | | | | iBGP 22.22.22.22 iBGP 33.33.33.33 | | (10.0.1.0/24 10.0.0.0/24) | | ( 10.0.0.0/16 ) | +---------------------------------------------------+ Figure 5: The case of Multi-homing Access In the scenario of single-homed user network access to the local network, ACL or strict uRPF can generally provide effective protection. However, in the case of multi-homed user network access, Cheng, et al. Expires December 27, 2024 [Page 9] Internet-Draft Intra-domain SAV Support via BGP June 2024 there may be asymmetric routing and the prefixes of asymmetric routes on the router may dynamically change to achieve dynamic load balancing. In this case, ACL or strict uRPF cannot be directly used to protect the user access interface as a allow-list, as this may lead to issues of misfiltering. In the mentioned network, Node C could receive packets with a source address of 10.0.0.0/24 via interface C-1, and Node A could receive similar packets via interface A-1, potentially causing misfiltering. Similarly, Node E could receive packets with a source address of 10.0.1.0/24 via interface E-1, and Node A could receive similar packets via interface A-2, leading to potential misfiltering of packets. To address this issue , one approach is to configure a static route (10.0.0.0/24, C-1) on the interface C-1 of Node C, and when advertising this route through BGP, specify a higher Prefer value than the Prefer value of this route on Node E. Similarly, on Node E, configure a static route (10.0.1.0/24, E-1) and when advertising it through BGP, specify a higher Prefer value than the Prefer value of this route on Node C. The resulting SAV entries are as follows: Entries on Node C: (10.0.1.0/24, C-1), (10.0.0.0/24, C-1) Entries on Node E: (10.0.0.0/24, E-1), (10.1.0.0/24, E-1) Entries on Node A: (10.0.1.0/24, A-1), (10.0.0.0/24, A-1) (10.0.1.0/24, A-2), (10.0.0.0/24, A-2) 3.5. BGP Source Prefix Filtering In actual network deployment, some source prefixes do not need to be filtered. To distinguish which source prefixes require filtering, BGP community attributes can be used to identify the source prefixes that require filtration. When the BGP protocol advertises a source prefix, it includes the specified community attribute to indicate that this source prefix requires SAV calculation. On the devices performing SAV calculation, SAV rules are generated only for routes with the specified community attribute. 4. Example +---------------------------------------------------------+ | AS | | iBGP 11.11.11.11 | | SAV Rule: +--------3-+ | Cheng, et al. Expires December 27, 2024 [Page 10] Internet-Draft Intra-domain SAV Support via BGP June 2024 | (10.0.0.0/24, A-1) | Router A | | | (20.0.0.0/24, A-1) +1--------2+ | | (30.0.0.0/24, A-2) /\ /\ | | / \ | | / \ | | / \ | / \ | RR +----------+ +----------+ | |iBGP | Router B | | Router E | iBGP | |55.55.55.55 +1--------2+ +---------1+ 66.66.66.66 | | /\ /\ /\ | | / \ \ | | / \ \ | | +----------+ +----------+ +----------+ | | | Router C | | Router D | | Router F | | | +----------+ +----------+ +----------+ | | | | | | | iBGP 22.22.22.22 iBGP 33.33.33.33 iBGP 44.44.44.44 | | P: 10.0.0.0/24 P: 20.0.0.0/24 P:30.0.0.0/24 | +---------------------------------------------------------+ Figure 7: Example 3 of Topology Calculation After conducting internal IGP calculations, on router A, it is determined that BGP neighbors reachable via A-1 are 22.22.22.22 and 33.33.33.33. BGP neighbor 44.44.44.44 is reachable via A-2. Following the source prefix calculation in BGP, inheriting the outgoing interface information from the connectivity calculation, router A can compute the following sav table entries: (10.0.0.0/24, A-1) obtained from BGP neighbor 22.22.22.22, (20.0.0.0/24, A-1) obtained from BGP neighbor 33.33.33.33, and (30.0.0.0/24, A-2) obtained from BGP neighbor 44.44.44.44. 5. Deployment Considerations 5.1. Intra-domain SAV Support via IGP and BGP If the network topology information and source prefix information within the domain are both conveyed by the IGP protocol, SAV rules can be automatically generated following the calculation method described in [draft-cheng-savnet-intra-domain-sav-IGP-00] or [I- D.lin-Intra-domain-savnet-method]. If in the network, the intra-domain network topology information is conveyed by the IGP protocol, while the intra-domain source prefix information is transmitted via the BGP protocol, this SAV Cheng, et al. Expires December 27, 2024 [Page 11] Internet-Draft Intra-domain SAV Support via BGP June 2024 calculation method can be deployed to generate SAV rules for preventing source address attacks in outbound and inbound traffic. If the intra-domain source prefixes are transmitted via BGP, while network connectivity information is conveyed by protocols other than IGP, this deployment can still be used to calculate SAV rules. The BGP protocol simply inherits the interfaces from the topological calculation into the final generated SAV rules, based on the next- hop information in the source prefixes. Furthermore, it is also possible to plan a separate BGP domain within the intra-domain, using BGP RR to reflect and propagate all intra-domain source prefixes. First, through IGP or other extended technologies, the SAV table entries corresponding to the next hops of BGP source prefixes are calculated. Finally, through the next hop of BGP, the SAV table entries of the next hops are obtained to generate the BGP-published source prefix SAV table entries, ultimately achieving BGP calculation SAVNET functionality within the intra-domain. 6. IANA Considerations This document does not involve IANA. 7. Security Considerations TBD 8. References 8.1. Normative References [I-D.ietf-savnet-intra-domain-architecture] Li, D., Wu, J., Huang, M., Chen, L., Geng, N., Qin, L., and F. Gao, "Intra-domain Source Address Validation (SAVNET) Architecture", Work in Progress, Internet-Draft, draft-li-savnet-intra-domain-architecture-03, 25 July 2023, . [I-D.lin-Intra-domain-savnet-method] D. Li,"Intra-domain SAVNET method", Work in Progress, Cheng, et al. Expires December 27, 2024 [Page 12] Internet-Draft Intra-domain SAV Support via BGP June 2024 8.2. Informative References [I-D.ietf-savnet-intra-domain-problem-statement] Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements", Work in Progress, Internet-Draft, draft-ietf-savnet-intra-domain-problem- statement-02, 17 August 2023, . Acknowledgments TBD Authors' Addresses Weiqiang Cheng China Mobile China Email: chengweiqiang@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Shengnan Yue China Mobile China yueshengnan@chinamobile.com Cheng, et al. Expires December 27, 2024 [Page 13]