SAVNET Working Group C. Lin Internet Draft Y. Qiu Intended status: Standards Track New H3C Technologies Expires: January 11, 2023 July 10, 2022 Intra-domain SAVNET method draft-lin-savnet-lsr-intra-domain-method-00 Abstract This document proposes a method of Source Address Validation in Intra-domain, which can be applied to OSPF and IS-IS protocols. By extending IGP and adding the protocol calculation procedure, the SAV information can be accurately calculated to realize the source address verification. 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 January 11 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Lin, et al. Expire January, 2023 [Page 1] Internet-Draft intra-domain savnet July 2022 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 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 2 1.1. Requirements Language .................................. 3 2. Calculating SAV information based on IGP extension .......... 3 3. Advertising the protected prefixes .......................... 4 4. Calculate SAV information based on IGP ...................... 4 5. Scenario of Multi-area ...................................... 7 6. Protocol extension .......................................... 8 6.1. Extension of OSPFv2 .................................... 8 6.1.1. Extension for protected prefixes .................. 8 6.1.2. Extension for reverse prefix cost ................. 9 6.2. Extension of OSPFv3 ................................... 10 6.2.1. Extension for protected prefixes ................. 10 6.2.2. Extension for reverse prefix cost ................ 11 6.3. Extension of IS-IS .................................... 12 6.3.1. Extension for protected prefixes ................. 12 6.3.2. Extension for reverse prefix cost ................ 12 7. Consideration of redirection routing policy ................ 13 8. IANA Considerations ........................................ 16 9. Security Considerations .................................... 16 10. References ................................................ 16 10.1. Normative References ................................. 16 Contributors .................................................. 17 Authors' Addresses ............................................ 18 1. Introduction There are long-term attacks based on source address spoofing in the Internet. By spoofing the source address, attackers can disguise themselves and carry out hacking activities including DOS and DDoS attacks, which have brought serious security threats to the entire Internet. Lin, et al. Expires January, 2023 [Page 2] Internet-Draft intra-domain savnet July 2022 [draft-li-sav-gap-analysis] describes the gap analysis of various current SAV methods. This document proposes a method based on the existing IGP routing protocol for the requirement of SAV in the domain. By extending the message of the routing protocol, adding the relevant protocol calculation procedure, each node has the ability to independently calculate the valid incoming interface of a specific prefix in domain, so as to verify the source address of the traffic. In addition, for the redirected forwarding policy independent of routing protocol, the impact on SAV information calculation is discussed. 1.1. Requirements Language 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. 2. Calculating SAV information based on IGP extension By extending the IGP routing protocol, each routing node calculates independently SAV information, that is, the binding entry including prefixes and valid incoming interfaces. If the source address of the received packet hits the prefix of a binding entry, and the interface belongs to the valid incoming interfaces bound with the prefix, the source address of the packet is considered legal, otherwise it is illegal. The existing URPF uses the source address of the packet to lookup the local route table when receiving the packet, and determines whether the packet is valid according to the lookup result. For strict URPF, it is required that the outgoing interface of the found route is consistent with the incoming interface of the packet; For loose URPF, only a route to the source address is required. However, the local route table is used to guide how to go from the local to the node and subnet where the source address is located, and it cannot really reflect how to reach this node from the node and subnet where the source address is located. Therefore, the local route table only has some reference value and cannot be fully trusted to validate the source address. Lin, et al. Expires January, 2023 [Page 3] Internet-Draft intra-domain savnet July 2022 The IGP needs to be extended to advertise specific prefix information. At the same time, each node that enables the intra- domain SAV function needs to calculate the SAV information according to the extended routing message. In addition, this document also considers the protocol extension required by the multi-area scenario. 3. Advertising the protected prefixes When advertising prefix information through IGP, it is necessary to identify the source prefix participating in SAV information calculation. These prefixes can be called protected prefixes. For intra-domain scenarios, it is mainly the access side prefix of each boundary node. Prefixes from outside the domain are considered in the inter-domain solution. If the loopback address and network side interface prefix of the node in the domain are considered to be safe, it is not necessary to participate in the calculation of SAV information. The prefix that needs to participate in SAV information calculation can be specified through configuration. When IGP advertises such a prefix, it needs to attach corresponding information to inform other routing nodes. When the router that has enabled the intra-domain SAV function receives the packet, only those packets whose source address comes from the protected prefixes will be checked for the legitimacy of the incoming interface of the packet. That is, if the legal interfaces of SAV information corresponding to the source prefix do not contain the incoming interface of the packet, it may be necessary to discard the packet or do other related processing to the packet. In order to identify the protected prefixes, the IGP protocol needs to be extended accordingly. The corresponding message extensions are described in Section 7. 4. Calculate SAV information based on IGP This section describes how to calculate SAV information based on the route information advertised by IGP. Referring to the following topology as an example, each router from R1 to R7 has an access subnet prefix. These prefixes are protected prefixes. Lin, et al. Expires January, 2023 [Page 4] Internet-Draft intra-domain savnet July 2022 subnet(p2) ,-----. subnet(p3) ( _) ,---------. `-----'-_ ( ) +----+ Intf1`-----+---' +------------+ R2 +-----------------+ / | +-+--+ +-+--+ | | | R3 | subnet(p1) | | +---------------+-+--+ ----. | | | Intf2 | Intf3 ( ) | | | | ---`: | | | subnet(p7) | `.+-+--+ +-+--+ ,---. +-+--+ | R1 +---------+ R7 +---( ) + R6 |`.subnet(p6) +-+--+ +-+--+ `---' +-+--+ `-,---. | | | | ( ) | | | | `---' | | | +-+--+ | | +---------------+ R5 |- | | +-+--+ ,`-.. | +-+--+ | ( ) +------------+ R4 +-----------------+ `---' -+----+ subnet(p5) subnet(p4) - ,------- ( ) `-------' Figure 1: example topology of intra-domain savnet Taking R3 as an example, after collecting the prefix and topology information in the domain through IGP, R3 first takes itself as the root, calculates a shortest path tree to other routers in the domain, and calculates the intra-domain route based on this shortest path tree. This process is consistent with the existing IGP route calculation process. R3 continues to take other routers in the domain as the root to calculate the shortest path tree. Finally, seven shortest path trees from Tree-R1 to Tree-R7 are generated on R3. R3 calculates SAV information corresponding to the protected prefix based on these trees. Take Prefix P1 as an example. Prefix P1 is advertised by R1. Therefore, R3 needs to calculate which interface the packet from R1 will reach the R3 from. The specific process is as follows. R1 will learn the route through IGP protocol, including the subnet prefix accessed by each router in the domain and the route to the Lin, et al. Expires January, 2023 [Page 5] Internet-Draft intra-domain savnet July 2022 outside of the domain. The logical next hop of these routes is actually other routing nodes. For R3, the received packet should be the following three cases: o The destination address of the packet is R3 or the subnet prefix accessed by R3. o The packet goes out of the AS or Area and hits inter-AS or inter- area route advertised by R3 as ASBR or ABR. At this time, R3 receives the packet as the logic next hop to these routes. o The route hit by the destination address of the packet is advertised by the downstream node of R3 on the Tree-R1. When forwarding, the packet will pass through R3 node and go to the downstream node of R3. Packets from R1 in these three cases can take R3 as the logical next hop, so the actual forwarding path of these packets is consistent with the actual forwarding path of the packet with the destination address of R3. Therefore, R3 can calculate the forwarding path of the packet from R1 to R3 based on the Tree-R1, and then get the physical interfaces of the packet from R1 to R3. Based on Tree-R1, the interface between R3 and the upstream node will be the actual interface of R3 receiving the packet which is from R1. As shown in the figure below, the intf1 interface of R3 is the legal incoming interface of packets from prefix P1. Lin, et al. Expires January, 2023 [Page 6] Internet-Draft intra-domain savnet July 2022 +----+ Intf1 +------------+ R2 +-----------------+ | +----+ +-+--+ | | R3 | | +-+--+ | |Intf3 | | | | +-+--+ +----+ +-+--+ | R1 +---------+ R7 + | R6 | +-+--+ +----+ +-+--+ | | | | | | +----+ | +---------------+ R5 | | +----+ | +----+ +------------+ R4 | +----+ Figure 2: Tree-R1 Repeat this process. Based on the shortest path tree with each router as the root, R3 can get the legal incoming interfaces of all protected prefixes in the domain, establish the binding entry, and guide the verification of the source address of the packet in forwarding plane. 5. Scenario of Multi-area In large-scale networks, an AS may be divided into different areas to avoid the problems caused by too many nodes. As shown in the following figure, an AS divided into two areas, each router is connected to the corresponding subnet, R1 is connected to P1, and so on, and R7 is connected to P7. Taking OSPFv2 as an example, R4 and R5, as ABRs, will convert the router LSA (type-1) of R6 and R7 in Area1 into network Summary LSA (type-3) and advertise it to the routers in Area0. Area0 to Area1 are also processed in the same way. The type-3 route received by R3 from R4 will include the subnet of R6, with an originator of R4 and a cost of 10. According to the method described in section 4, R3 will calculate the valid incoming interface of P6 as intf1. If the cost of the two directions of the link between R4 and R6 is different for some reason, for example, the cost from R4 to R6 is 10, but the cost in the reverse direction is 100, which will cause Lin, et al. Expires January, 2023 [Page 7] Internet-Draft intra-domain savnet July 2022 the packet sent by R6 to arrive at R3 from intf2 actually. The type- 3 route advertised by R4 to R3 has only one-way cost from R4 to R6, which cannot reflect the real situation. In order to accurately calculate SAV information in the scenarios of multi-area, it is necessary to expand the type-3 route and advertise the cost in reverse directions between ABR and a prefix at the same time. That is, when R4 advertises the prefix information of R6, it carries cost of 10 and reverse cost of 100 at the same time. Similarly, the cost of R6 network prefix information advertised by R5 in two directions is 40 and 50 respectively. area1 area0 +-------------------------+ +-------------------------------+ | | | | * cost 100(<-) * * intf1 +-+-+-+(->)cost 10 +-----+ | | +----+ +-------+ R4 +-------------+ R6 | * * | R1 +---------+ | +-+-+-+ +--+--+ | | +----+ ++--++ | | cost20 | * * | R3 | * * (<->) | | | ++--++ | | | * * +----+ | | +-+-+-+(->)cost 20 +--+--+ | | | R2 +---------+ +-------+ R5 +-------------+ R7 | * * +----+ intf2 +-+-+-+ cost 30(<-) +-----+ | | | | * +-------------------------------+ +-------------------------+ Figure 3: example topology of multi-area When ABR that enables SAV function advertises network Summary LSA (type-3), ABR needs to calculate the total cost from the node where the prefix in LSA is located to this ABR, and advertises it together through protocol extension. By extending the protocol, R3 can be aware that packets from P6 and P7 will arrive at R3 from R5, so the valid incoming interface of the two protected prefixes can be calculated as intf2. 6. Protocol extension 6.1. Extension of OSPFv2 6.1.1. Extension for protected prefixes A sub-TLV called Prefix-SAV sub-TLV is defined to identify a protected prefix. The Prefix-SAV Sub-TLV is a sub-TLV of the OSPF Extended Prefix TLV described in [RFC7684]. Lin, et al. Expires January, 2023 [Page 8] Internet-Draft intra-domain savnet July 2022 When the Route Type of OSPFv2 Extended Prefix TLV is Intra-Area (1) or Inter-Area (3), prefix-SAV sub-TLV can be used to identify the prefix. It SHOULD appear only once in the parent TLV and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD1. Length: 4 octets. Flags: Reserved flag field. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception According to the current definition, if this sub-TLV appears in ospfv2 extended prefix TLV, it means that the prefix in the message is protected prefixes. 6.1.2. Extension for reverse prefix cost A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the total costs from the router where the prefix is located to reach ABR. The Prefix-Reverse-cost Sub-TLV is a sub-TLV of the OSPF Extended Prefix TLV described in [RFC7684]. When the Route Type of OSPFv2 Extended Prefix TLV is Inter-Area (3), Prefix-Reverse-cost sub-TLV can be used. Lin, et al. Expires January, 2023 [Page 9] Internet-Draft intra-domain savnet July 2022 It SHOULD appear only once in the parent TLV and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reverse metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD2. Length: 4 octets. Rreverse metric: Total cost value from the router where the prefix is located to ABR. 6.2. Extension of OSPFv3 6.2.1. Extension for protected prefixes A sub-TLV called prefix-SAV sub-TLV is defined to identify a protected prefix. The Prefix-SAV sub-TLV is a sub-TLV of the following OSPFv3 TLVs as defined in [RFC8362] and in Section 5: Intra-Area Prefix TLV Inter-Area Prefix TLV It SHOULD appear only once in the parent TLV and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lin, et al. Expires January, 2023 [Page 10] Internet-Draft intra-domain savnet July 2022 where: Type: TBD3. Length: 4 octets. Flags: Reserved flag field.. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception 6.2.2. Extension for reverse prefix cost A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the total cost from the router where the prefix is located to reach ABR. The Prefix-Reverse-cost sub-TLV is a sub-TLV of the following OSPFv3 TLVs as defined in [RFC8362] and in Section 5: Inter-Area Prefix TLV It SHOULD appear only once in the parent TLV and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD4. Length: 4 octets. Reverse metric: Total cost value from the router where the prefix is located to ABR. Lin, et al. Expires January, 2023 [Page 11] Internet-Draft intra-domain savnet July 2022 6.3. Extension of IS-IS 6.3.1. Extension for protected prefixes A sub-TLV called Prefix-SAV sub-TLV is defined to identify protected prefixes. The Prefix-SAV sub-TLV is a sub-TLV of the following IS-IS TLVs: TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. TLV-235 (Multi-topology IPv4 Reachability) defined in [RFC5120]. TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. TLV-237 (Multi-topology IPv6 IP Reachability) defined in [RFC5120]. It SHOULD appear only once in the parent TLV and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Reversed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD5. Length: 2 octets. Flags: Reserved flag field. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception 6.3.2. Extension for reverse prefix cost A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the total cost from the router where the prefix is located to reach ABR. Lin, et al. Expires January, 2023 [Page 12] Internet-Draft intra-domain savnet July 2022 The Prefix-Reverse-cost sub-TLV is a sub-TLV of the following of the following IS-IS TLVs: TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. TLV-235 (Multi-topology IPv4 Reachability) defined in [RFC5120]. TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. TLV-237 (Multi-topology IPv6 IP Reachability) defined in [RFC5120]. When the level 2 router leaks routes through the above TLVs, Prefix- Reverse-cost sub-TLV can be used to carry reverse total cost. It SHOULD appear only once in the parent TLV and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD6. Length: 4 octets. Reverse metric: Total cost value from the router where the prefix is located to ABR. 7. Consideration of redirection routing policy In the actual deployment, some redirected forwarding policies may be used, such as PBR and QoS. The forwarding path of the packets processed by these policies may be inconsistent with the routing table, resulting in a router receiving the packets forwarded based on the routing table and the packets forwarded based on the Lin, et al. Expires January, 2023 [Page 13] Internet-Draft intra-domain savnet July 2022 redirected forwarding policies from different interfaces. Therefore, when calculating SAV information, the influence of redirected forwarding policy should also be taken into account. Because the redirected forwarding policy is very complicated, this section only describes a relatively simple scenario. More in-depth and detailed analysis and discussion are expected to be added in future versions. The redirected forwarding policy can be deployed on any node in the domain. These policies specify the characteristics of the packet, as well as the outgoing interface and next hop to redirect the packet. After a router applies this forwarding policy, the packets matching the characteristics specified by the policy will be forwarded according to the path specified by the policy, and its forwarding path may be different from the route learned through IGP. The packet characteristics of redirection routing policy often contain a lot of information, including source and destination addresses, Port number, protocol number and other information. Only the source and destination addresses participate in the calculation of SAV information. If a redirected forwarding policy specifies only L4 information, the source and destination addresses are considered to match all; similarly, if a redirection policy is only configured with destination address characteristics, the source address is considered to match all Redirected forwarding policies can be divided into the following categories: o (Src, dest, M, nexthop): Both source and destination prefixes are specified, as well as the next hop. M identifies whether other non-address fields are specified. If so, it indicates that the redirection policy only works on part of the traffic, and it needs to be calculated based on the routing and redirection policies at the same time; If not, it means that this policy will affect all packets matching the source and destination prefixes, and these packets can no longer calculate SAV information according to the routing. o (*, dest, M, nexthop): Only the destination prefix and next hop are specified. M has the same meaning as above. * means to match all source addresses, that is, there is no restriction on source addresses. o (Src, *, M, nexthop): Only the source prefix and next hop are specified. M has the same meaning as above. Lin, et al. Expires January, 2023 [Page 14] Internet-Draft intra-domain savnet July 2022 o (*, *, M, nexthop): The source and destination prefixes are not specified, and M must be yes at this time. If some nodes in the domain have enabled the redirected forwarding policy, when calculating the SAV information, R3 cannot rely on a single shortest path tree, but also needs to collect the redirected forwarding policy of relevant nodes to calculate the valid incoming interface for the packet from R1 to R3. The redirected forwarding policy is complex and needs to be considered comprehensively based on the information of multiple nodes. This document takes a simple case as an example to illustrate the calculation process 1. Assume that R1 and R7 are configured with redirection policies as follows: R1 (*, dst1, Yes, R7) R7 (*, dst1, Yes, R3) Dst1 is the route prefix advertised by R3. According to these policies, the forwarding path of some packets from R1 to dst1 is R1->R7->R3. But the forwarding path according to the route should be R1->R2->R3. 2. After receiving the redirection policy advertised by R1, R3 finds that dst1 is the routing prefix advertised by itself, and can know that the next hop specified by the redirection rule is R7. 3. If there is no matching redirection policy on R7, then according to tree-R7, the next hop to dst1 is R2, which is the upstream node of R3 on tree-R1, and R2 also has no redirection policy. Then there is no need to continue the calculation. That is, the current redirection policy will not increase the incoming interface for R3 to receive packets from R1. 4. If there is also a matching redirection policy on R7, and the next hop is R3, then intf2 of R3 also needs to be the valid incoming interface of the packet from R1. Lin, et al. Expires January, 2023 [Page 15] Internet-Draft intra-domain savnet July 2022 +----+ 10 | R2 +-----------------+ +-+--+ +-+--+ | | R3 | | +-+--+ 10 | | | | 10 | | +----+ 10 +-+--+ +-+--+ | R1 +---------+ R7 | | R6 | +-+--+ +-_--+ +----+ | | | | 10| | 10 +----+ | +---------------+ R5 | | +----+ | +----+ +------------+ R4 | +----+ Figure 4: Tree-R7 The actual situation is more complicated. The redirected forwarding policies configured on different nodes may specify different packet characteristics, so the affected prefix range is also different. Therefore, the calculation of SAV information based on redirected forwarding policy needs further analysis and discussion. 8. IANA Considerations TBD. 9. Security Considerations This document does not introduce any new security consideration. 10. References 10.1. Normative References [I-D.li-sav-gap-analysis] Li, D., Wu, J., Huang, M., Qin, L., Geng, N., " Source Address Validation: Use Cases and Gap Analysis ", draft-li-sav-gap-analysis-01 (work in progress), January 2022 Lin, et al. Expires January, 2023 [Page 16] Internet-Draft intra-domain savnet July 2022 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . Contributors Lin, et al. Expires January, 2023 [Page 17] Internet-Draft intra-domain savnet July 2022 Authors' Addresses Changwang Lin New H3C Technologies Email: linchangwang.04414@h3c.com Yuanxiang Qiu New H3C Technologies Email: qiuyuanxiang@h3c.com Lin, et al. Expires January, 2023 [Page 18]