idnits 2.17.1 draft-li-opsec-sav-gap-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC8704], [RFC2827], [RFC3704]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 5, 2021) is 1023 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3704' is mentioned on line 22, but not defined == Missing Reference: 'AS1 AS2' is mentioned on line 234, but not defined == Missing Reference: 'AS4 AS3' is mentioned on line 239, but not defined == Missing Reference: 'AS2' is mentioned on line 243, but not defined == Missing Reference: 'AS3' is mentioned on line 242, but not defined == Missing Reference: 'P1' is mentioned on line 303, but not defined == Missing Reference: 'P2' is mentioned on line 307, but not defined == Missing Reference: 'P3' is mentioned on line 307, but not defined == Missing Reference: 'RFC6482' is mentioned on line 339, but not defined == Unused Reference: 'I-D.brockners-inband-oam-requirements' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-grow-bmp-adj-rib-out' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-grow-bmp-local-rib' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'I-D.openconfig-rtgwg-gnmi-spec' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'I-D.song-ntf' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC3719' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC3988' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC6232' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC7854' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC8210' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC8231' is defined on line 483, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-11 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 3 errors (**), 0 flaws (~~), 31 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Li 3 Internet-Draft J. Wu 4 Intended status: Informational Tsinghua 5 Expires: January 6, 2022 Y. Gu 6 Huawei 7 L. Qin 8 Tsinghua 9 T. Lin 10 H3C 11 July 5, 2021 13 Soure Address Validation: Gap Analysis 14 draft-li-opsec-sav-gap-analysis-02 16 Abstract 18 This document identifies scenarios where existing IP spoofing 19 approaches for detection and mitigation don't perform perfectly. 20 Exsiting SAV (source address validation) approaches, either Ingress 21 ACL filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) 22 [RFC3704], Feasible Path uRPF [RFC 3704], or Enhanced Feasible-Path 23 uRPF [RFC8704] has limitations regarding eihter automated 24 implemetation objective or detection accuracy objective (0% false 25 positive and 0% false negative). This document provides the gap 26 analysis of the exsting SAV approaches, and also provides solution 27 discussions. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 6, 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Source Address Validation . . . . . . . . . . . . . . . . 2 70 1.2. Existing SAV Techniques Overview . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Use Case 1: Inter-AS Multi-homing . . . . . . . . . . . . 5 74 3.2. Use Case 2: Intra-AS Multi-homing . . . . . . . . . . . . 6 75 4. Solution Discussions . . . . . . . . . . . . . . . . . . . . 8 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 79 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 1.1. Source Address Validation 86 The Internet is open to traffic, which means that a sender can 87 generate traffic and send to any receiver in the Internet as long as 88 the address is reachable. Although this openness design improves the 89 scalability of the Internet, it also leaves security risks, e.g., a 90 sender can forge the source address when sending the packets, which 91 is also known as IP spoofing. IP spoofing is constantly used in 92 Denial of Service (DoS) attacks, which seriously compromise network 93 security. DOS attacks using IP spoofing makes it difficult for 94 operators to locate the attacker's actual source address. [RFC6959] 95 identifies different types of DOS attacks with IP spoofing, i.e., 96 single-packet attack, flood-based DoS, poisoning attack, spoof-based 97 worm/malware propagation, reflective attack, accounting subversion, 98 man-in-the-middle attack, third-party recon, etc. 100 1.2. Existing SAV Techniques Overview 102 Source address validation (SAV) verifies the authenticity of the 103 packet's source address to detect and mitigate IP spoofing [RFC2827]. 104 Existing methods, such as Source Address Validation Improvement 105 (SAVI) [RFC7039], unicast Reverse Path Forwarding (uRPF) (i.e., 106 Strict uRPF, Feasible uRPF and Loose uRPF) [RFC3704], as well as 107 Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) 108 methods [RFC8704] are deployed at different network levels to prevent 109 IP spoofing. 111 Overall, when evaluating a SAV technique, one should consider the 112 following two perspectives. 114 1) Precise filtering: Two important indicators for precise filtering. 115 1) 0% false positive (FP) rate. If legitimate packets are 116 dropped, it can seriously affect the user experience. 2) 0% false 117 negative (FN) rate. If some packets with a forged source address 118 passes, it poses potential security risks. 120 2) Automatic implementation: In practice, the address space may grow, 121 and routing policies may be dynamically adjusted. SAV solutions 122 that rely entirely on manual configuration are either non-scalable 123 or error-prone. 125 SAVI, typically performed at the access network, is enforced in 126 switches, where the mapping relationship between an IP address and 127 other "trust anchor" is maintained. A "trust anchor" can be link- 128 layer information (such as MAC address), physical port of a switch to 129 connect a host, etc. It enforces hosts to use legitimate IP source 130 addresses. However, given numerous access networks managed by 131 different operators, it is far from practice for all the access 132 networks to simultaneously deploy SAVI. Therefore, in order to 133 mitigate the security risks raised by source address spoofing, SAV 134 performed in network border routers is also necessary. Although it 135 does not provide the same filtering granualarity as SAVI does, it 136 still helps the tracing of spoofing to a minimized network range. 138 Ingress ACLs [RFC2827], typically performed at the network border 139 routers, is performed by manually maintaining a traffic filtering 140 access list which contains acceptable source address for each 141 interface. Only packets with a source address encompassed in the 142 access list can be accepted. It strictly specifies the source 143 address space of incoming packets. However, manual-based filtering 144 method is error-prone and face scalability issues. 146 Strict uRPF, typically performed at the network (IGP areas or ASes) 147 border routers, requires that a data packet can be only accepted when 148 the FIB contains a prefix that encompasses the source address and the 149 corresponding out-interface matches the data incoming interface. It 150 has the advantages of simple operation, easy deployment, and 151 automatic update. However, in case of multihoming, when the data 152 imcoming interface is different from the out-interface, which is also 153 refered to as asymmetric routing of data packets, Strict uRPF exibits 154 FP. 156 Loose uRPF, sacrificing the directionality of Strict uRPF, only 157 requires that the packet's source IP exists as a FIB entry. 158 Intuitively, Loose uRPF cannot prevent the attacker from forging a 159 source address that already exists in the FIB, which incurs FN 160 detection. 162 Feasible uRPF (FP-uRPF), typically performed at the network border 163 routers, helps mitigate FP of Strict uRPF in the multihoming 164 scenarios. Instead of installing only the best route into FIB as 165 Strict uRPF does, Feasible uRPF installs all alternative paths into 166 the FIB. It helps reduce FP filtering compared with the Strict uRPF, 167 in the case when multiple paths are learnt from different interfaces. 168 However, it should be noted that Feasible uRPF only works when 169 multiple paths are learnt. There are cases when a device only learns 170 one path but still has packets coming from other valid interfaces. 171 Thus, FP-uRPF performs better than Loose uRPF regarding FP detection, 172 but still doesn't not guarantee 0% FP. 174 EFP-uRPF, specifically performed at the AS border routers, further 175 improves FP-uRPF in the inter-AS scenario. An ASBR, performing EFP- 176 uRPF, maintains an RPF filtering list on each customer/peer 177 interface. It introduces two algorihtms (i.e., Algorithm A and 178 Algorithm B) regarding different application scenarios. In the case 179 that a customer interface fails to learn any route from a directly 180 connected customer AS, enabling Algorithm A at this customer 181 interface may exibit false postive detection. In this case, 182 Algorithm B can mitigate the FP. However, in case of two customer 183 ASes spoofing each other, Algorithm B exibits FN. 185 This document specifically identifies two scenarios, where the above 186 mentioned SAV techniques, i.e., Strict uRPF, Loose uRPF, FP-uRPF, and 187 EFP-uRPF, fail to guarantee 0% FP and 0% FN detection. 189 2. Terminology 191 IGP: Interior Gateway Protocol 193 IS-IS: Intermediate System to Intermediate System 194 BGP: Boarder Gateway Protocol 196 RIB: Routing Information Base 198 FIB: Forwarding Information Base 200 SAV: Source Address Validation 202 AD: Administrative Domain 204 3. Problem Statement 206 3.1. Use Case 1: Inter-AS Multi-homing 208 Figure 1 illustrates an inter-AS multihoming case. 210 AS2 is multi-homed to AS1 and AS4. AS2 announces P1/P2 to AS1 211 through BGP. AS2 doesn't announce any of its routes to AS4 due to 212 policy control. P1/P2 are propagated from AS1 to AS4 through BGP. 214 AS3 is single-homed to AS4. AS3 announces P3 to AS4 through BGP. 215 AS4 propagates P3 to AS1 through BGP. 217 Now suppose two data flows coming from AS2 to AS4: Flow 1 with source 218 IP as P1, and Flow 2 with source IP as P3 (IP spoofing). Using 219 existing SAV methods at AS4, Flow 1 is supposed to be passed, while 220 Flow 2 is supposed to be dropped. 222 o Loose uRPF: works for Flow 1, but fails for Flow 2. 224 o Strict uRPF: works for Flow 2, but fails for Flow 1 (the incoming 225 interface does not match P1/P2's out-interface). 227 o FP-uRFP: works for Flow 2, but fails for Flow 1 (no feasible path 228 for P1/P2 other than the best route exists). 230 o EFP-uRPF: works for Flow 1, but fails for Flow 2 using Algorithm 231 B. Works for Flow 2, but fails for Flow 1 when using Algorithm A. 233 P1[AS1 AS2] 234 P2[AS1 AS2] 235 +---------------+ (C2P) +---------------+ 236 | +------------------> | 237 | AS1 | | AS4 | 238 | <------------------+ | 239 +----+/\+-------+ P3[AS4 AS3] ++/\+-----+/\+--+ 240 \ (P2C) / \ 241 \ / \ 242 P1[AS2] [no prefix adv] P3[AS3] 243 P2[AS2] / \ 244 (C2P) \ / (C2P) \ (C2P) 245 \ / \ 246 \ / \ 247 +---------------------+ +---------------+ 248 | | | | 249 | AS2(customer) | | AS3(customer) | 250 | | | | 251 +---------------------+ +---------------+ 252 P1,P2(prefixes originated) P3(prefix originated) 254 Figure 1: Asymmetric data flow in the Inter-AS scenario 256 3.2. Use Case 2: Intra-AS Multi-homing 258 Figure 2 illustrates an intra-AS multihoming case. To facilitate 259 management, one AS can be divided into several administrative domains 260 (ADs) and managed by different inner groups. In Figure 2, AD1 is the 261 upper level compared to AD2 and AD3, meaning that AD2 or AD3 needs to 262 connect through AD1 for external reachability (i.e., networks outside 263 AD1). For example, AD1 is the backbone of one national education 264 network, while AD2 and AD3 are the campus networks of the two 265 universities. 267 Router 1 is multi-homed to Router 2 and Router 3. No dynamic routing 268 protocol set up between Router 1 and Router 2, as well as between 269 Router 1 and Router 3. In AD2, static routes to outside AD2 are 270 configured on Router 1 with Router 3 as the next hop. In AD1, static 271 route to P1 is configured on Router 2 and static route to P2 is 272 configured on Router 3, due to traffic control purpose. Router 2 and 273 Router 3 are connected with each other using ISIS or OSPF. 275 Router 5 is single-homed to Router 3. In AD3, static routes to 276 outside AD3 are configured on Router 5 with Router 3 as the next hop. 277 In AD1,static route to P3 is configured on Router 3 with Router 5 as 278 the next hop. 280 Now suppose two data flows coming from Router 1 to Router 3: Flow 1 281 with source IP as P1, and Flow 2 with source IP as P3 (IP spoofing). 282 Using existing SAV methods at Router 3, Flow 1 is supposed to be 283 passed, while Flow 2 is supposed to be dropped. 285 o Loose uRPF: works for Flow 1, but fails for Flow 2. 287 o Strict uRPF: works for Flow 2, but fails for Flow 1 (the incoming 288 interface does not match P1's out-interface). 290 o FP-uRFP: works for Flow 2, but fails for Flow 1 (no feasible path 291 for P1 other than the best route exists). 293 o EFP-uRPF: does not apply at the intra-AS case. 295 +----------------------------------------------------------------------+ 296 | AS | 297 | +--------------------------------+ | 298 | | AD1 +------------+ | | 299 | | | Router 4 | | | 300 | | +-/\------/\-+ | | 301 | Router 2 | / \ | Router 3 | 302 | Static RIB: | / \ | Static RIB: | 303 | Prefix: P1 | +--------+ [P1] +--------+ | Prefix: P2 | 304 | NH: Router 1 | | +----------> | | NH: Router 1 | 305 | | |Router 2| |Router 3| | Prefix: P3 | 306 | IGP RIB: | | <----------+ | | NH: Router 5 | 307 | Prefix: P2 | +--------+ [P2,P3] +--------+ | | 308 | NH: Router 3 +---/\-----------------/\----/\--+ IGP RIB: | 309 | Prefix: P3 \ / \ Prefix: P1 | 310 | NH: Router 3 \ / \ NH: Router 2 | 311 | \ / \ | 312 | [no prefix adv] [no prefix adv] [no prefix adv] | 313 | \ / \ | 314 | +-------\-------/----+ +------\---------+ | 315 | |AD2 +----------+ | |AD3 +--------+ | | 316 | | | Router 1 | | | |Router 5| | | 317 | | +----------+ | | +--------+ | | 318 | | P1,P2 | | P3 | | 319 | +--------------------+ +----------------+ | 320 | P1,P2(prefixes originated) P3(prefix originated) | 321 | | 322 +----------------------------------------------------------------------+ 324 Figure 2: Asymmetric data flow in the Intra-AS scenario 326 4. Solution Discussions 328 Both EFP-uRPF and FP-uRPF try to achieve a balance between 329 flexibility (Loose uRPF) and directionality (Strict uRPF). 331 In the inter-AS multi-homing scenario, EFP-uRPF further improves FR- 332 uRPF's directionality. The key improvement of EFP-uRPF is that it 333 synchronizes certain information between interfaces that share the 334 same RPF filtering list, so as to construct an RPF list as 335 comprehensive as possible, although [RFC8704] does not explicitly 336 specify how the information is synchronized, e.g., what information, 337 in which format and in which way. In addition, the construction of 338 RPF lists can be further augmented with data from Route Origin 339 Authorization (ROA) [RFC6482], as well as Internet Routing Registry 340 (IRR) data. In fact, the global availability of ROA and IRR 341 databeses provides a secondary information synchronization approach. 342 However, EFP-uRPF still fails to achieve 0% FN and 0% FP in case of 343 Figure 1. Further infomration synchronization between interfaces 344 might provide further improvement. 346 The above description works similarly for the intra-AS scenario. 347 Information synchronization is also required in order to achieve 348 higher filtering accuracy. 350 5. Security Considerations 352 TBD 354 6. Contributors 356 TBD 358 7. Acknowledgments 360 TBD 362 8. Normative References 364 [I-D.brockners-inband-oam-requirements] 365 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 366 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 367 T., <>, P. L., and R. Chang, "Requirements for In-situ 368 OAM", draft-brockners-inband-oam-requirements-03 (work in 369 progress), March 2017. 371 [I-D.ietf-grow-bmp-adj-rib-out] 372 Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. 373 Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring 374 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-07 (work 375 in progress), August 2019. 377 [I-D.ietf-grow-bmp-local-rib] 378 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 379 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 380 draft-ietf-grow-bmp-local-rib-11 (work in progress), April 381 2021. 383 [I-D.ietf-netconf-yang-push] 384 Clemm, A. and E. Voit, "Subscription to YANG Notifications 385 for Datastore Updates", draft-ietf-netconf-yang-push-25 386 (work in progress), May 2019. 388 [I-D.openconfig-rtgwg-gnmi-spec] 389 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 390 C., and C. Morrow, "gRPC Network Management Interface 391 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 392 progress), March 2018. 394 [I-D.song-ntf] 395 Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z., 396 Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a 397 Network Telemetry Framework", draft-song-ntf-02 (work in 398 progress), July 2018. 400 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 401 "Simple Network Management Protocol (SNMP)", RFC 1157, 402 DOI 10.17487/RFC1157, May 1990, 403 . 405 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 406 DOI 10.17487/RFC1191, November 1990, 407 . 409 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 410 dual environments", RFC 1195, DOI 10.17487/RFC1195, 411 December 1990, . 413 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 414 for Network Management of TCP/IP-based internets: MIB-II", 415 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 416 . 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 424 Defeating Denial of Service Attacks which employ IP Source 425 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 426 May 2000, . 428 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 429 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 430 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 431 . 433 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 434 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 435 2004, . 437 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 438 Networks using Intermediate System to Intermediate System 439 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 440 . 442 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 443 Signalling Extensions for the Label Distribution 444 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 445 . 447 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 448 Originator Identification TLV for IS-IS", RFC 6232, 449 DOI 10.17487/RFC6232, May 2011, 450 . 452 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 453 and A. Bierman, Ed., "Network Configuration Protocol 454 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 455 . 457 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address 458 Validation Improvement (SAVI) Threat Scope", RFC 6959, 459 DOI 10.17487/RFC6959, May 2013, 460 . 462 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 463 "Source Address Validation Improvement (SAVI) Framework", 464 RFC 7039, DOI 10.17487/RFC7039, October 2013, 465 . 467 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 468 S. Ray, "North-Bound Distribution of Link-State and 469 Traffic Engineering (TE) Information Using BGP", RFC 7752, 470 DOI 10.17487/RFC7752, March 2016, 471 . 473 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 474 Monitoring Protocol (BMP)", RFC 7854, 475 DOI 10.17487/RFC7854, June 2016, 476 . 478 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 479 Infrastructure (RPKI) to Router Protocol, Version 1", 480 RFC 8210, DOI 10.17487/RFC8210, September 2017, 481 . 483 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 484 Computation Element Communication Protocol (PCEP) 485 Extensions for Stateful PCE", RFC 8231, 486 DOI 10.17487/RFC8231, September 2017, 487 . 489 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 490 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 491 RFC 8704, DOI 10.17487/RFC8704, February 2020, 492 . 494 Authors' Addresses 496 Dan Li 497 Tsinghua 498 Beijing 499 China 501 Email: tolidan@tsinghua.edu.cn 503 Jianping Wu 504 Tsinghua 505 Beijing 506 China 508 Email: jianping@cernet.edu.cn 509 Yunan Gu 510 Huawei 511 Beijing 512 China 514 Email: guyunan@huawei.com 516 Lancheng Qin 517 Tsinghua 518 Beijing 519 China 521 Email: qlc19@mails.tsinghua.edu.cn 523 Tao Lin 524 H3C 525 Beijing 526 China 528 Email: lintao@h3c.com