SAVNET Group X. Song Internet-Draft C. Dai Intended status: Best Current Practice ZTE Corporation Expires: 12 April 2025 S. Yue China Mobile C. Lin New H3C Technologies 9 October 2024 BGP Operations for Inter-domain SAVNET draft-song-savnet-inter-domain-bgp-ops-03 Abstract This document attempts to present BGP policy-based solution for source address validation in inter-domain networks. 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 12 April 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 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. Song, et al. Expires 12 April 2025 [Page 1] Internet-Draft BGP Policy for Inter-domain SAV October 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. BGP Policy-based Solution . . . . . . . . . . . . . . . . . . 4 4. General Solution Considerations . . . . . . . . . . . . . . . 4 4.1. Secure Domain . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Prefix-to-Interface Mapping . . . . . . . . . . . . . . . 5 4.3. SAV Function . . . . . . . . . . . . . . . . . . . . . . 6 5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Multi-homing Scenarios . . . . . . . . . . . . . . . . . . . 7 6.1. Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . 10 7. Implementation and Operation Considerations . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11. Normative References . . . . . . . . . . . . . . . . . . . . 13 12. Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction It is well known that internet routing security challenges include: route leaks, route prefix hijacking and source address spoofing. To address these challenges, Resource Public Key Infrastructure (RPKI) provides an approach to build a formally verifiable database of IP addresses and AS numbers as resources. And there are RPKI-based BGP Prefix Origin Validation (POV) (see [RFC7115]) and BGP AS path validation (see [I-D.ietf-sidrops-aspa-verification]) to mitigate route leaks. The Route Origin Authorization currently used for RPKI- ROA (see [RFC6811], [RFC9319]) prevents hijacking of route prefix. Source Address Validation (SAV) is one feasible way to filter invalid address and mitigate source address spoofing attacks in the data plane. To help reduce source address spoofing attacks in networks the feasible way is to validate whether the source address is spoofed or not. The security requirement is the ability to validate the accuracy of incoming interface of the traffic for specific IP address prefixes. More specifically, one router needs to validate that the incoming interface receiving the source IP address prefixes is in fact the right interface. This document describes a BGP validation mechanism to satisfy this security requirement in inter-domain networks. Song, et al. Expires 12 April 2025 [Page 2] Internet-Draft BGP Policy for Inter-domain SAV October 2024 As analyzed at [I-D.ietf-savnet-inter-domain-problem-statement], there are existing urpf-like mechanisms which describe an approach to build source address filtering. However, the urpf technologies may improperly permit spoofed traffic or block legitimate traffic. For example, strict uRPF (see [RFC3704]) technology is a simple way to implement and provides a very reasonable way to single-homing scenarios for ingress filtering. But in asymmetrical or multi-homing scenarios it brings wrong block for logic source address prefixes. Loose URPF [RFC3704] takes a looser validation mechanism than strict URPF to avoid improper block but may permit improperly spoofed source address. However, the urpf technologies may improperly permit spoofed traffic or block legitimate traffic. The FP-uRPF (see [RFC3704]) attempts to strike the banlance of the strict and loose uRPF but still has some shortcoming. The EFP-uRPF (see [RFC8704]) provides a more feasible way in overcoming the improper block of strict uRPF in asymetric routing scenario, but EFP-uRPF has not been implemented in practical networks yet. The BGP validation mechanism introduced in this document aims to reduce false positives regarding invalid incoming interface, mitigate source address spoofing, resolve the inflexibility about directionality of strict-URPF to improve accuracy of source address validation in inter-domain networks. It also provides deployment considerations for Source Address Validation using BGP in inter- domain networks. 2. Conventions 2.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.2. Terminology The following terms in this document are used: 1. Prefix: Has the content (IP address, prefix length), interpreted as customary (see [RFC4632]). 2. Incoming Interface: The interface which received the traffic of source route prefixes. 3. Route Prefix: The prefix derived from a route. 4. Secure Domain Identifier: A tag for BGP source prefix Secure Domain Identification (SDI). Song, et al. Expires 12 April 2025 [Page 3] Internet-Draft BGP Policy for Inter-domain SAV October 2024 3. BGP Policy-based Solution From the perspective of BGP implementation architecture, to address the threats which includes route leaks, route prefix hijacking and source address spoofing, the key for secure communication is to protect the integrity and authenticity of BGP information. The secure technology includes origin and path authentication. The origin authentication means to protect the mapping between the prefix and its corresponding origin AS. RPKI (see [RFC6480], [RFC6493], [RFC7128]) can be used to support route prefix origin authentication. The path authentication means to protect the entire AS_path of BGP route prefix. BGPsec (see [I-D.ietf-sidr-bgpsec-protocol]) is used to address this issue. Meanwhile, BGPsec relies on RPKI which obtains ROA (Route Origin Authentication) to verify the authenticity of prefix origins (AS numbers mapping with IP address prefixes) and router certificates to prove the router represent an AS an its public key. Refer to [RFC5210], the inter-AS domain SAVNET networks are classified into 2 cases: 1. Two SAV-compliant ASes exchanging traffic are directly connected; 2. Two SAVA-compliant ASes are separated by one or more intervening, non-SAVA-compliant providers. For case 1, it's obvious that the combined methods BGPsec as well as RPKI and ROA can be used to address source address spoofing attacks. For case 2, the document introduces an optional new SAV method which called BGP policy-based solution for dis-adjacent AS domains. It's noted that the existing SAV methods (e.g., uRPF, ACL, etc.) can also be implemented in combination with BGP policy-based method considering the internet network area is so large. 4. General Solution Considerations This document introduces a BGP policy-based solution for inter-domain SAVNET. The main considerations are showed as follows: 1. Secure Domain Indicator (SDI),Each secure domain MUST be assigned a secure domain indicator (SDI) which MUST be unique within the reachable network. The secure domain may be managed by SAVNET controller or management system, which can be ISPs or 3-party organizations. The secure domain management system is responsible for the lifecycle management of SDIs, including joining, modifying and leaving from one specific secure domains. Song, et al. Expires 12 April 2025 [Page 4] Internet-Draft BGP Policy for Inter-domain SAV October 2024 2. Export policy for prefix SDI advertisement, which describes the policy for prefix advertisement. The document introduces secure domain method for mapping of source prefix packets. A secure domain which is a collection of source prefixes (can also be AS, router, etc.) which communicate with confidentiality and authenticity guarantees using a shared secret. The secure domain identifier can be the same and can be different across multi- domains which may be mapped. 3. Import policy for interface SDI mapping, which is applied to the incoming interface of received packets for filtering through policy mapping of packets. It means the incoming interface SHOULD create the mapping policy with SDI for specific secure domain filtering. 4. SAVNET rules gerneration, which describes the mapping rules of prefix with the incoming interface of packets. The prefix-to- interface mapping is introduced in the section 4.2. 5. SAV validation function, decision process which uses comparing results for validation of import policy with the ingress packets. The SAV function for the decision is introduced in section 4.3. 4.1. Secure Domain A central concept for the BGP SAV method is to use secure domain for mapping of source prefix (which may also be AS, router, etc.) for secure network communication. The secure domain is added when BGP prefix is advertised to its BGP neighbor. The Secure Domain Identifier (SDI) can be managed by SAVNET controller or be configured route-map policy by SAVNET Agent. The secure domain spans from route prefix to all routers within domains. The document does not exclude the same secure domain SDI cross multiple domains. The premise here is the different secure domain identifier should be mapped or binded for validation of inter- domain SAVNET networks. If one specific source prefix packets scheduled in a secure domain while need be filtered for specific secure requirement, then the existing SAV methods, for example ACL and QoS policy are considered to be in combination used with BGP policy-based solution. 4.2. Prefix-to-Interface Mapping The document assumes that Source Address Validation needs only be done by edge routers (or AS boarder routers) in a network and is deployed on current routers without significant hardware upgrades. The BGP policy-based method introduced in this document does not need to update current routers with hardware upgrades nor big software updates. The mapping policy described in this section used for Song, et al. Expires 12 April 2025 [Page 5] Internet-Draft BGP Policy for Inter-domain SAV October 2024 SAVNET rules generation should be used in boarder routers (i.e., ASBR) from other large networks (such as small stub, enterprise, edge networks, etc.). The deployment for prefix-to-interface mapping policy on routers is verified locally using BGP policy-based validation method which is listed as the following: 1. Create prefix-to-interface mapping policy and apply the policy to the incoming interface of the source address received from the packets of one specific address prefix. It means that the secure domain is set for the incoming interface of the traffic, the security domain identifier is matched with the SDI carried in the route prefix message entering this interface, and a mapping table (or SAVNET rule or mapping table) between this interface and the route prefix is generated. 2. When the source prefix packets are received that will be validated whether the SDI tag carried in the BGP route prefix is mapped with the incoming interface. If mapped, the packets received are permit to transit; if not, the packets received should be discarded or redirected to other interfaces based-on the deployed route policy. The filtering SAV function is introduced in section 4.3. 4.3. SAV Function An implementation should provide the ability to match the validation policy and set validation state of routes as part of its source address validation policy SAV function. The SAV function involves 2 characters: source address prefix and incoming interface. The objectives of SAV function include (1) set prefix-to-interface mapping of BGP route prefix from BGP neighbor with the incoming interface as route policy deployed at the edge routers, (2) match the validation mapping policy and (3) decide the validation state for the source address. When the traffic of one specific address prefix received at one interface of the edge routers, the validation policy should be deployed and filtered the source address. And based-on the validation state the source address should be validated correctly. The validation state is considered to include: * Valid: The address prefix of received traffic matches the incoming interface. * Invalid: The address prefix of received traffic does not match the incoming interface. * NotFound: The address prefix of received traffic is not found. Song, et al. Expires 12 April 2025 [Page 6] Internet-Draft BGP Policy for Inter-domain SAV October 2024 When the source address received of traffic which prefix derived from the BGP route is not matched with the incoming interface, the validation state is considered as "Invalid". Only the prefix matched with the incoming interface the validation state is set as "valid". Similarly, if no valid route be found its corresponding address packets should be discarded and its validation state should be set as "NotFound". 5. Scalability The secure domain can be deployed as different granularity to satisfy scalability requirements for source address validation. The document provides the following policies: * AS level Secure Domain Identifier (AS SDI): The AS number information which can be obtained along the prefix advertisement is used for SAV filtering policy. * Community level Secure Domain Identifier (Community SDI): The policy uses BGP Community feature for source address validation. It may require BGP extentions to carry the necessary SDI information. * Router level Secure Domain Identifier (Router SDI): This is one practical way to reuse some of the existing fields to indicate the directionality or location of the source packets belong to. The policy suggests to use router-id as SDI. * Prefix level Secure Domain Identifier (Prefix SDI): The policy is the smallest filtering granularity for source address validation. The traffic packets received at incoming interface of BGP ASBR are validated by the SDI. Considering the inter BGP domains may be managed by different operators, the Prefix SDI is recommended be deployed as local policy. 6. Multi-homing Scenarios This section provides examples for the BGP policy-based method for inter-domain SAVNET networks. 6.1. Scenario 1 In terms of the URPF technologies may improperly permit spoofed traffic or block legitimate traffic, the URPF enhancements for solving limitations of strict URPF for inter-domain networks is mainly on improvement of ingress filtering accuracy in multi-homing scenarios. The following figure 1 shows an example for Content Delivery Networks (CDN) service access to Service Provider Networks (SPN) through the Internet Service Provider (ISP) networks. For the ISPs are outside Song, et al. Expires 12 April 2025 [Page 7] Internet-Draft BGP Policy for Inter-domain SAV October 2024 networks of SPN, the SPN needs to verify the validity of source address prefix of traffic received from ISPs. The CDN1 announces source prefix A to the ISP100 and ISP200, announces source prefix B to ISP100, and prefix C to ISP200. The POP1 (Point of Presence) is the point or infrastructure used for access of ISP100 and ISP200. The POP1 learns routes directly connected ISPs and some non-directly connected ISPs/CDNs from multiple ISPs. The set of routes learned from the same non-directly connected ISP is inconsistent but overlapped. It's assumed that the prefix from ISPs in the following figure are trusted. Prefix:A,B,D,F +------------+ /--| ISP100 |---\ +---------+ / +------------+ \ | SP | /1 \ Prefix: A,B,C | +----+ +----------+ | |POP1| | CDN1 | | +----+ +----------+ +---------| \2 +------------+ / \---| ISP200 |---/ +------------+ Prefix:A,C,E,F Figure 1: SAV Functions for CDN Multi-homing Scenario It's assumed that the SDI for the prefix origin from ISP100 is set as 100, and SDI for ISP200 is set as 200. The prefix-to-interface mapping rule is based-on AS level and is showed as the below table 1. Song, et al. Expires 12 April 2025 [Page 8] Internet-Draft BGP Policy for Inter-domain SAV October 2024 +========+=========+===========+ | Prefix | SDI | Interface | +========+=========+===========+ | A | 100,200 | 1,2 | +--------+---------+-----------+ | B | 100 | 1 | +--------+---------+-----------+ | C | 200 | 2 | +--------+---------+-----------+ | D | 100 | 1 | +--------+---------+-----------+ | E | 200 | 2 | +--------+---------+-----------+ | F | 100,200 | 1,2 | +--------+---------+-----------+ Table 1: Prefix-to-Interface Mapping When the packets received in POP1 the source address is validated using prefix-to-interface mapping rule. For example, prefix A tagged with SDI 100 and 200, respectively matched with Int1 and Int2 of POP1, so the packets of prefix A will be permitted to transit by Int1 and Int2. For prefix B tagged with SDI 100 can only be permitted by Int1 according to the prefix-to-interface mapping rule. Similarly, the prefix F comes from both ISP1 and ISP2 will be permitted by Int1 and Int2. The SAV actions table shows as table 2. Song, et al. Expires 12 April 2025 [Page 9] Internet-Draft BGP Policy for Inter-domain SAV October 2024 +===========+========+========+ | Interface | Prefix | Action | +===========+========+========+ | 1 | A | Permit | +-----------+--------+--------+ | 1 | B | Permit | +-----------+--------+--------+ | 1 | C | Deny | +-----------+--------+--------+ | 1 | D | Permit | +-----------+--------+--------+ | 1 | E | Deny | +-----------+--------+--------+ | 1 | F | Permit | +-----------+--------+--------+ | 2 | A | Permit | +-----------+--------+--------+ | 2 | B | Deny | +-----------+--------+--------+ | 2 | C | Permit | +-----------+--------+--------+ | 2 | D | Deny | +-----------+--------+--------+ | 2 | E | Permit | +-----------+--------+--------+ | 2 | F | Permit | +-----------+--------+--------+ Table 2: SAV Action In this case, the prefix from the same origin (i.e., AS number) as a whole set is trusted and the prefix-to-interface mapping rule is applied to the incoming interfaces of traffic received for source validation in routers. 6.2. Scenario 2 The following figure 2 shows an example of multipoint interconnection between multiple POP points and the same ISP. In this case, the set of routes learned from different POP points to the same ISP is inconsistent but overlapped. This section provides 2 SDI policies apllied in AS-level and Router-level. Song, et al. Expires 12 April 2025 [Page 10] Internet-Draft BGP Policy for Inter-domain SAV October 2024 +----------------------------------+ | ISP200 | +----------------------------------+ | | | | Prefix:A,C| |Prefix:A,B,C Prefix:A,B| 1 | 2 | 3 +----+ +----+ +----+ +--|POP1|-------|POP2|-----|POP3|--+ | +----+ +----+ +----+ | | \ | / | | \ | / | | \ | / | | +---------------+ | | | RR | | | +---------------+ SP | +----------------------------------+ Figure 2: SAV Functions for Multiple POPs Access Scenario In this case, the prefix-to-interface mapping rule shows as the table 3. +========+=====+===========+ | Prefix | SDI | Interface | +========+=====+===========+ | A | 200 | 1,2,3 | +--------+-----+-----------+ | B | 200 | 1,3 | +--------+-----+-----------+ | C | 200 | 2,3 | +--------+-----+-----------+ Table 3: Prefix-to- Interface Mapping If AS SDI applied in the case the traffic packets of prefix (i.e., A, B and C in this example) received at POP1 from AS 200 are treated from the same trusted source. If the SDI policy replaced by router SDI the packets of prefix C will be filtered and processed as invalid source address at POP1 in this example. Through BGP method provided in this document, the SAV function is applied by BGP edge routers (i.e., SAV validation node) using prefix- to-interface rules to complete source address validation accurately. It's obvious that the BGP method described in section 5.1 and 5.2 improves the source address validation accuracy and overcomes the limitation of strict URPF method in multi-homing scenarios. Song, et al. Expires 12 April 2025 [Page 11] Internet-Draft BGP Policy for Inter-domain SAV October 2024 7. Implementation and Operation Considerations The source address validation is selected for filtering invalid address or mitigating source address spoofing through validating the incoming interface of traffic received for one specific source prefix is in fact the right interface. The mapping policy as discussed in section 3 can be used to take action and based on the validation state to complete SAV function introduced in section 4 for address filtering. The policies can be implemented include (1) identifying the route prefix advertised by different ISPs(i.e., BGP neighbors) as same or different SDIs. (2) applying Prefix-to-Interface mapping policy to the BGP Edge routers (or AS Boarder routers) and process the Source Address Validation (SAV) function. (3) making the corresponding action based-on the validation state. The validating router uses the result of source address validation to influence local policy in one network. In deployment, the policy should fit into the routers existing policy and allows a network to deploy incrementally or partially. The prefix-to-interface mapping rules used by the BGP edge routers are expected to be updated based- on the real network requirement. The following operational considerations applied to the BGP validation mechanism: * The BGP validation mechanism SHOULD support backward compatibility with existing routers. * The BGP validation mechanism SHOULD be hardware friendly, does not require hardware upgrades nor big software updates. * The BGP validation mechanism SHOULD comply with the routers existing policies and allow for incremental and partial network deployment. * The BGP validation mechanism SHOULD support actual network implement requirement. 8. Security Considerations The BGP method introduced in this document provides a feasible way to validate address of traffic received for one specific source prefix. In this document, the BGP route prefix in inter-domain network is considered as trusted. If there are invalid routes which are not matched with the current BGP route table should be blocked. The validation of origination AS of BGP routes is introduced in BGP POV document (see [RFC6811]). This document attempts to verify the incoming interface is in fact the right interface for the source prefix and provide a flexible way for source address validation. The Song, et al. Expires 12 April 2025 [Page 12] Internet-Draft BGP Policy for Inter-domain SAV October 2024 inter-domain SAV security refers to [I-D.wu-savnet-inter-domain-architecture]. For the secure domain method introduced in this document, The secure domain may be managed by SAVNET controller or management system. The secure domain management system is responsible for the life-cycle management of SDIs. It's noted that the communication of assignment and processing of SDIs should be secured. 9. IANA Considerations This document has no requests for IANA. 10. Acknowledgements The authors would like to acknowledge Wei Yuehua, Xiao Min, Liu Yao, Zhou Fenlin for their thorough review and feedbacks. 11. Normative References [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, . 12. Informative References [I-D.ietf-savnet-inter-domain-problem-statement] Li, D., Wu, J., Liu, L., Huang, M., and K. Sriram, "Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements", Work in Progress, Internet-Draft, draft-ietf-savnet-inter-domain-problem- statement-05, 8 September 2024, . [I-D.ietf-sidr-bgpsec-protocol] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", Work in Progress, Internet-Draft, draft- ietf-sidr-bgpsec-protocol-23, 27 April 2017, . Song, et al. Expires 12 April 2025 [Page 13] Internet-Draft BGP Policy for Inter-domain SAV October 2024 [I-D.ietf-sidrops-aspa-verification] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa- verification-19, 27 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, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [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, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . Song, et al. Expires 12 April 2025 [Page 14] Internet-Draft BGP Policy for Inter-domain SAV October 2024 [RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, . [RFC7128] Bush, R., Austein, R., Patel, K., Gredler, H., and M. Waehlisch, "Resource Public Key Infrastructure (RPKI) Router Implementation Report", RFC 7128, DOI 10.17487/RFC7128, February 2014, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . [RFC9319] Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B. Maddison, "The Use of maxLength in the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 9319, DOI 10.17487/RFC9319, October 2022, . Authors' Addresses Xueyan Song ZTE Corporation China Email: song.xueyan2@zte.com.cn Chunning Dai ZTE Corporation China Email: dai.chunning@zte.com.cn Shengnan Yue China Mobile China Email: yueshengnan@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Song, et al. Expires 12 April 2025 [Page 15]