idnits 2.17.1 draft-li-sava-intra-domain-use-cases-00.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], [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 12, 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3704' is mentioned on line 21, but not defined == Missing Reference: 'P1' is mentioned on line 388, but not defined == Missing Reference: 'P2' is mentioned on line 388, but not defined == Missing Reference: 'P3' is mentioned on line 395, but not defined == Missing Reference: 'RFC6482' is mentioned on line 424, but not defined == Unused Reference: 'I-D.brockners-inband-oam-requirements' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-grow-bmp-adj-rib-out' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-grow-bmp-local-rib' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'I-D.openconfig-rtgwg-gnmi-spec' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'I-D.song-ntf' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC3719' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC3988' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC6232' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC7854' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC8231' is defined on line 580, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-07 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 3 errors (**), 0 flaws (~~), 26 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 13, 2021 Y. Gu 6 Huawei 7 L. Qin 8 Tsinghua 9 T. Lin 10 H3C 11 July 12, 2020 13 Soure Address Validation Architecture (SAVA): Intra-domain Use Cases 14 draft-li-sava-intra-domain-use-cases-00 16 Abstract 18 This document identifies scenarios where existing approaches for 19 detection and mitigation of source address spoofing don't perform 20 perfectly. Either Ingress ACL filtering [RFC3704], unicast Reverse 21 Path Forwarding (uRPF) [RFC3704], feasible path uRPF [RFC 3704], or 22 Enhanced Feasible-Path uRPF [RFC8704] has limitations regarding 23 eihter automated implemetation objective or detection accuracy 24 objective (0% false positive and 0% false negative). This document 25 identifies two such scenarios and provides solution discussions. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 13, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Source Address Validation . . . . . . . . . . . . . . . . 2 69 1.2. Existing SAV Techniques Overview . . . . . . . . . . . . 3 70 1.3. SAV Requirements and Challenges . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. SAVA Intra-domain Use Case 1: Intra-AS Multi-homing . . . 7 74 3.2. SAVA Intra-domain Use Case 2: Inter-AS Multihoming . . . 8 75 4. Solution Consideration . . . . . . . . . . . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. Normative References . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 without 88 permission of the receiver. Although this openness design improves 89 the scalability of the Internet, it also leaves security risks, 90 namely, a sender can forge his/her source address when sending the 91 packets, which is also well known as source address spoofing. 93 Due to the lack of source address spoofing detection mechanism, 94 Denial of Service (DoS) attacks seriously compromise network 95 security. By employing source address spoofing, attackers can well 96 hide themselves and pin the blame on the destination networks. 97 Administrators often spend a lot of effort identifying attack packets 98 without being able to locate the attacker's true source address. In 99 addition to DOS attacks, source address spoofing is also used in a 100 multitude of ways. The threats of source address spoofing have been 101 well documented in [RFC6959]. To briefly summarize, the possible 102 attacks by source address spoofing includes single-packet attack, 103 flood-based DoS, poisoning attack, spoof-based worm/malware 104 propagation, reflective attack, accounting subversion, man-in-the- 105 middle attack, third-party recon, etc. 107 1.2. Existing SAV Techniques Overview 109 Source address validation (SAV) verifies the authenticity of the 110 packet's source address to detect and mitigate source address 111 spoofing [RFC2827]. Source Address Validation Improvement (SAVI) 112 method [RFC7039] implements SAV at a fine granularity of host-level 113 IP address validataion. The unicast Reverse Path Forwarding (uRPF) 114 techniques (such as Strict uRPF, Feasible uRPF and Loose uRPF) 115 [RFC3704] are particularly designed to perform SAV in the granularity 116 of IP network. The Enhanced Feasible-Path Unicast Reverse Path 117 Forwarding (EFP-uRPF) methods [RFC8704] further improve Feasible uRPF 118 to reduce false positives in the case of inter-AS routing asymmetry 119 and multihoming. 121 SAVI, typically performed at the access network, is enforced in 122 switches, where the mapping relationship between an IP address and 123 other "trust anchor" is maintained. A "trust anchor" can be link- 124 layer information (such as MAC address), physical port of a switch to 125 connect a host, etc. It enforces hosts to use legitimate IP source 126 addresses. However, given numerous access networks managed by 127 different operators, it is far away from practice for all the access 128 networks to simultaneously deploy SAVI. Therefore, in order to 129 mitigate the security risks raised by source address spoofing, SAV 130 performed in network border routers is also necessary. Although it 131 does not provide the same filtering granualarity as SAVI does, it 132 still helps the tracing of spoofing to a minimized network range. 134 Ingress ACLs [RFC2827], typically performed at the network border 135 routers, is performed by manually maintaining a traffic filtering 136 access list which contains acceptable source address for each 137 interface. Only packets with a source address encompassed in the 138 access list can be accepted. It strictly specifies the source 139 address space of incoming packets. However, manual configuration 140 brings scalability and reliability issues. 142 Strict uRPF, typically performed at the network (IGP areas or ASes) 143 boarder routers, requires that a data packet can be only accepted 144 when the FIB contains a prefix that encompasses the source address 145 and the corresponding out-interface matches the data incoming 146 interface. It has the advantages of simple operation, easy 147 deployment, and automatic update. However, in the case of 148 multihoming, when the data imcoming interface is different from the 149 out-interface of the packet source IP address, using the longest 150 prefix match , also refered to as asymmetric routing of data packets, 151 Strict uRPF exibits false positive. 153 Loose uRPF, sacrificing the directionality of Strict uRPF, only 154 requires that the packet's source IP exists as a FIB entry. 155 Intuitively, Loose uRPF cannot prevent the attacker from forging a 156 source address that already exists in the FIB. 158 Feasible uRPF, typically performed at the network border routers, 159 helps mitigate false positive of Strict uRPF in the multihoming 160 scenarios. Instead of installing only the best route into FIB as 161 Strict uRPF does, Feasible uRPF installs all alternative paths into 162 the FIB. It helps reduce false positive filtering compared with the 163 Strict uRPF, in the case when multiple paths are learnt from 164 different interfaces. However, it should be noted that Feasible uRPF 165 only works when multiple paths is learnt. There are cases when a 166 device only learns one path but still has packets coming from other 167 valid interfaces. 169 EFP-uRPF, specifically performed at the AS border routers, further 170 improves Feasible uRPF in the inter-AS scenario. An AS performing 171 EFP-uRPF maintains an individual RPF list on every customer/peer 172 interface. It introduces two algorihtms (i.e., Algorithm A and 173 Algorithm B) regarding different application scenarios. In the case 174 that a customer interface fails to learn any route from the directly 175 connected customer AS, enabling Algorithm A at this customer 176 interface may exibit false postive filtering. In this case, enabling 177 Algorithm B may mitigate the false positive. However, in case of 178 directly connected customer ASes spoofing each other, Algorithm B 179 exibits false negative. 181 1.3. SAV Requirements and Challenges 183 As the above overview indicates, to evaluate the quality of a 184 specific SAV technique, one should balance between two general 185 requirements: precise filtering and automatic implementation. 187 o Precise filtering: Two important indicators for precise filtering. 188 1) 0% false positive. If legitimate packets may be dropped, it 189 can seriously affect the user's internet experience. 2) 0% false 190 negative. If some packets with a forged source address may pass 191 through the SAV smoothly, it will pose potential security risks. 193 o Automatic implementation: In reality, the address space of an 194 administrative domain (AD) may grow or update, and the routing 195 policy within the address domain may be dynamically adjusted. One 196 solution that relies entirely on manual configuration is neither 197 scalable nor easy to deploy. 199 Then to consider the whole network SAV soltuion, one should never 200 rely on a single point but a systematic SAV technique combination 201 depoyled at different network levels. As shown in Figure 1, packet 202 filtering at different levels from the access network to the AS 203 boarder are all needed. In Figure 1, the administrive domain (AD) 204 concept is used, which refers to a network domain managed by the same 205 operator (OTT, ISP and so on). One AD is allowed to be divided into 206 several sub-ADs and managed by different inner groups. There may 207 exist different levels for sub-ADs. For example, sub-AD1 is the 208 upper level compared to sub-AD2, meaning that sub-AD2 needs to 209 connect through sub-AD1 for external reachability (i.e., networks 210 outside AD1). So filtering at sub-AD boarders (between different 211 levels and within the same level) is also necessary. Further, 212 different sub-ADs can belong to one single AS or multiple ASes, which 213 makes the filtering at the sub-AD boarders either intra-AS filtering 214 or inter-AS filetering. In the rest of this document, we use the 215 term SAVA (SAV architecture) to refer to the discussion of the 216 systematic SAV solution. 218 +-------------------------------------+ 219 | AD1 | 220 | | 221 | +---------------------------------+ | 222 | | Sub-AD1 +--------+ | | 223 | | |Router 4| | | +-------------+ 224 | | +--X---X-+ | | | AD2 | 225 | | X X | | | +--------+ | 226 | | X X | | +-----------+Router 6| | 227 | | X X | | + | +--------+ | 228 | | +---X----+ +---X+--------+ SAVA-Inter| | 229 | | |Router 2| |Router 3| | | Domain | | 230 | | +--- X---+ +--X+-----------+ | +--------+ | 231 | +-------- X ---------- X ---------+ | +-----------+Router 5| | 232 | X X SAVA-Intra | | +--------+ | 233 | +-----------+X------ X+--Domain---+ | +-------------+ 234 | | sub-AD2 +X-----X-+ | | 235 | | |Router 1| | | 236 | | ++-----+-+ | | 237 | | | | | | 238 | | | | | | 239 | | | | | | 240 | | +-------++ ++-------+ | | 241 | | |Switch 1| |Switch 2| | | 242 | | ++------++ ++-------+ | | 243 | | | | | SAVA-Access| | 244 | | | | | (SAVI) | | 245 | | | | | | | | 246 | | +--+-+ +--+-+ ++---+ ++---+ | | 247 | | |Host| |Host| |Host| |Host| | | 248 | | +----+ +----+ +----+ +----+ | | 249 | +---------------------------------+ | 250 | | 251 +-------------------------------------+ 253 Figure 1: SAVA 255 Looking back at specific SAV approaches, most limitations are caused 256 by multihoming. Further, it is due to the routing information 257 asymmetry at the mutil-homed devices. This document identifies two 258 specific scenarios where existing SAV techniques fail to meet the 259 above mentioned requirements. 261 2. Terminology 263 IGP: Interior Gateway Protocol 265 IS-IS: Intermediate System to Intermediate System 266 BGP: Boarder Gateway Protocol 268 FIB: Forwarding Information Base 270 SAV: Source Address Validation 272 SAVA: Source Address Validation Architecture 274 AD: Administrative Domain 276 3. Problem Statement 278 As stated in Section 1.3, existing methods, e.g., Loose/Strict mode 279 uRPF, FP-uRPF, EFP-uRPF are not able to achieve 100% accurate 280 filtering (i.e., 0% FN and 0% FP) in certain scenarios. This 281 document specifically indicate two typical intra-domain cases that 282 conventional approaches fail to cover: 1) all sub-ADs are under the 283 same AS; 2) sub-ADs are under different ASes. 285 3.1. SAVA Intra-domain Use Case 1: Intra-AS Multi-homing 287 Figure 2 illustrates an intra-AS multihoming case, where sub-AD1, 288 sub-AD2 and sub-AD3 are under the same AS. 290 Router 1 is multi-homed to Router 2 and Router 3. Router 1 doesn't 291 announce any of its routes to Router 2 nor Router 3. Static routes 292 are configured on Router 1, Router 2 and Router 3. Supposely, both 293 Router 2 and Router 3 should have static routes P1/P2 with Router 1 294 as next hop configured. However, due to configuration error, or 295 traffic control purpose, on Router 3, no P1/P2 static routes are 296 configured. Router 2 and Router 3 are connected with ISIS or OSPF. 297 P1/P2 are flooded from Router 2 to Router 3. 299 Router 5 is single-homed to Router 3. Router 5 announces P3 to 300 Router 3 using ISIS or OSPF. Router 3 floods P3 to Router 2 . 302 Now suppose two data flow coming from Router 1 to Router 3: Flow 1 303 with source IP as P1, and Flow 2 with source IP as P3 (IP spoofing). 304 Using existing SAV methods at Router 3, Flow 1 is supposed to be 305 passed, while Flow 2 is supposed to be dropped. 307 o Loose uRPF: works for Flow 1, but fails for Flow 2. 309 o Strict uRPF: works for Flow 2, but fails for Flow 1 (the incoming 310 interface does not match P1/P2's out-interface). 312 o FP-uRFP: works for Flow 2, but fails for Flow 1 (no feasible path 313 for P1/P2 other than the best route exists). 315 o EFP-uRPF: does not apply at the intra-AS case. 317 +----------------------------------------------------------------+ 318 | AS +--------------------------------+ | 319 | |sub-AD1 +--------+ | | 320 |Static: | |Router 4| | Static: NA | 321 |Prefix: P1 | +--X---X-+ | | 322 |NH: Router 1 | X X | IGP: | 323 |Prefix: P2 | X X | Prefix: P1 | 324 |NH: Router 1 | +--------+ [P1,P2] +--------+ | NH: Router 2 | 325 | | | +----------> | | Prefix: P2 | 326 |IGP: | |Router 2| |Router 3| | NH: Router 2 | 327 |Prefix: P3 | | +<---------+ | | Prefix: P3 | 328 |NH: Router 3 | +--------+ [P3] +--------+ | NH: Router 5 | 329 | +-------X---------------X------X-+ | 330 | X X X | 331 | [no prefix adv] [no prefix adv] X [P3] | 332 | X X X | 333 | +----------+X------ X+----------+ +--X+---------+ | 334 | |sub-AD2 +X-----X-+ | |sub-AD3 | | 335 | | |Router 1| | | +---X----- | | 336 | | ++-----+-+ | | |Router 5| | | 337 | | P1 | | P2 | | +--------- | | 338 | | | | | | P3 | | 339 | | +-------++ ++-------+ | +-------------+ | 340 | | |Switch 1| |Switch 2| | | 341 | | ++------++ ++------++ | | 342 | | | | | | | | 343 | | +--+-+ +--+-+ ++---+ ++---+ | | 344 | | |Host| |Host| |Host| |Host| | | 345 | | +----+ +----+ +----+ +----+ | | 346 | +-------------------------------+ | 347 +----------------------------------------------------------------+ 349 Figure 2: Asymmetric data flow in the Intra-AS scenario 351 3.2. SAVA Intra-domain Use Case 2: Inter-AS Multihoming 353 Figure 3 illustrates an inter-AS multihoming case, where sub-AD1, 354 sub-AD2 and sub-AD3 are under three different ASes. 356 Router 1 (AS2) is multi-homed to Router 2 (AS1) and Router 3 (AS1). 357 Router 1 announces P1/P2 to Router 2 through BGP. Router 1 doesn't 358 announce any of its routes to Router 3 due to policy control. P1/P2 359 are propagated from Router 2 to Router 3 through BGP. 361 Router 5 (AS3) is single-homed to Router 3 (AS1). Router 5 announces 362 P3 to Router 3 through BGP. Router 3 propagates P3 to Router 2 363 through BGP. 365 Now suppose two data flow coming from Router 1 to Router 3: Flow 1 366 with source IP as P1, and Flow 2 with source IP as P3 (IP spoofing). 367 Using existing SAV methods at Router 3, Flow 1 is supposed to be 368 passed, while Flow 2 is supposed to be dropped. 370 o Loose uRPF: works for Flow 1, but fails for Flow 2. 372 o Strict uRPF: works for Flow 2, but fails for Flow 1 (the incoming 373 interface does not match P1/P2's out-interface). 375 o FP-uRFP: works for Flow 2, but fails for Flow 1 (no feasible path 376 for P1/P2 other than the best route exists). 378 o EFP-uRPF: works for Flow 1, but fails for Flow 2 using Algorithm 379 B. Works for Flow 2, but fails for Flow 1 when using Algorithm A. 381 +----------------------------------------------------------------+ 382 | +--------------------------------+ | 383 | |sub-AD1 +--------+ | | 384 | |AS1 |Router 4| | | 385 | BGP: | +--X---X-+ | BGP: | 386 | Prefix: P1 | X X | Prefix: P1 | 387 | NH: Router 1| X X | NH: Router 2 | 388 | Prefix: P2 | +--------+ [P1,P2] +--------+ | Prefix: P2 | 389 | NH: Router 1| | +----------> | | NH: Router 2 | 390 | | |Router 2| |Router 3| | | 391 | Prefix: P3 | | +<---------+ | | Prefix: P3 | 392 | NH: Router 3| +--------+ [P3] +--------+ | NH: Router 5 | 393 | +-------X---------------X------X-+ | 394 | X X X | 395 | [P1/P2] X [no prefix adv] X [P3] | 396 | X X X | 397 | +----------+X------ X+----------+ +--X+---------+ | 398 | |sub-AD2 +X-----X-+ | |sub-AD3 | | 399 | |AS2 |Router 1| | |AS3 X | | 400 | | ++-----+-+ | | +---X----- | | 401 | | P1 | | P2 | | |Router 5| | | 402 | | | | | | +--------- | | 403 | | +-------++ ++-------+ | | P3 | | 404 | | |Switch 1| |Switch 2| | +-------------+ | 405 | | ++------++ ++------++ | | 406 | | | | | | | | 407 | | +--+-+ +--+-+ ++---+ ++---+ | | 408 | | |Host| |Host| |Host| |Host| | | 409 | | +----+ +----+ +----+ +----+ | | 410 | +-------------------------------+ | 411 +----------------------------------------------------------------+ 413 Figure 3: Asymmetric data flow in the Inter-AS scenario 415 4. Solution Consideration 417 Both EFP-uRPF and FP-uRPF try to achieve a balance between 418 flexibility (Loose uRPF) and directionality (Strict uRPF). 420 In the inter-AS multi-homing scenario, EFP-uRPF further improves FR- 421 uRPF's directionality, thanks to the availability of the route origin 422 information. More specifically, the construction of RPF lists using 423 EFP-uRPF Algorithm A or B is augmented with data from Route Origin 424 Authorization (ROA) [RFC6482], as well as Internet Routing Registry 425 (IRR) data, making EFP-uRPF performing better than FR-uRPF regarding 426 directionality. In fact, the global availability of ROA and IRR 427 databeses provides a way for the multiple transit providers of the 428 same multihomed network to share such information without extra way 429 of data syncronization. 431 In addition, although ERP-uRPF is striving for more accurate RPF list 432 construction, there's still currenly no way of constructing an 100%- 433 accurate RPF list in the case shown in Figure 3. In order to to 434 conquer such problem, it could help if devices in the upper level 435 sub-AD(s) (i.e., Router 2 and Router 3) can share more information 436 with each other through certain way. 438 What's worse, in case of the intra-AS multi-homing, as indicated in 439 Figure2, there's no such prefix to sub-AD mapping (e.g., P3 440 originates from sub-AD3) database publiclly available as ROA or IRR 441 database, or automatically retrievable as RPKI ROA through RTR 442 protocol [RFC8210]. Thus, enhancing such information sharing between 443 devices of the upper level sub-AD(s) (i.e., Router 2 and Router 3) 444 for the same multi-homed network, by extending certain routing 445 protocols, could be a possible way. 447 5. Security Considerations 449 TBD 451 6. Contributors 453 TBD 455 7. Acknowledgments 457 TBD 459 8. Normative References 461 [I-D.brockners-inband-oam-requirements] 462 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 463 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 464 T., Lapukhov, P., and r. remy@barefootnetworks.com, 465 "Requirements for In-situ OAM", draft-brockners-inband- 466 oam-requirements-03 (work in progress), March 2017. 468 [I-D.ietf-grow-bmp-adj-rib-out] 469 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 470 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 471 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-07 (work 472 in progress), August 2019. 474 [I-D.ietf-grow-bmp-local-rib] 475 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 476 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 477 draft-ietf-grow-bmp-local-rib-07 (work in progress), May 478 2020. 480 [I-D.ietf-netconf-yang-push] 481 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 482 draft-ietf-netconf-yang-push-25 (work in progress), May 483 2019. 485 [I-D.openconfig-rtgwg-gnmi-spec] 486 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 487 C., and C. Morrow, "gRPC Network Management Interface 488 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 489 progress), March 2018. 491 [I-D.song-ntf] 492 Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z., 493 Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a 494 Network Telemetry Framework", draft-song-ntf-02 (work in 495 progress), July 2018. 497 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 498 "Simple Network Management Protocol (SNMP)", RFC 1157, 499 DOI 10.17487/RFC1157, May 1990, 500 . 502 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 503 DOI 10.17487/RFC1191, November 1990, 504 . 506 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 507 dual environments", RFC 1195, DOI 10.17487/RFC1195, 508 December 1990, . 510 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 511 for Network Management of TCP/IP-based internets: MIB-II", 512 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 513 . 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 521 Defeating Denial of Service Attacks which employ IP Source 522 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 523 May 2000, . 525 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 526 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 527 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 528 . 530 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 531 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 532 2004, . 534 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 535 Networks using Intermediate System to Intermediate System 536 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 537 . 539 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 540 Signalling Extensions for the Label Distribution 541 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 542 . 544 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 545 Originator Identification TLV for IS-IS", RFC 6232, 546 DOI 10.17487/RFC6232, May 2011, 547 . 549 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 550 and A. Bierman, Ed., "Network Configuration Protocol 551 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 552 . 554 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address 555 Validation Improvement (SAVI) Threat Scope", RFC 6959, 556 DOI 10.17487/RFC6959, May 2013, 557 . 559 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 560 "Source Address Validation Improvement (SAVI) Framework", 561 RFC 7039, DOI 10.17487/RFC7039, October 2013, 562 . 564 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 565 S. Ray, "North-Bound Distribution of Link-State and 566 Traffic Engineering (TE) Information Using BGP", RFC 7752, 567 DOI 10.17487/RFC7752, March 2016, 568 . 570 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 571 Monitoring Protocol (BMP)", RFC 7854, 572 DOI 10.17487/RFC7854, June 2016, 573 . 575 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 576 Infrastructure (RPKI) to Router Protocol, Version 1", 577 RFC 8210, DOI 10.17487/RFC8210, September 2017, 578 . 580 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 581 Computation Element Communication Protocol (PCEP) 582 Extensions for Stateful PCE", RFC 8231, 583 DOI 10.17487/RFC8231, September 2017, 584 . 586 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 587 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 588 RFC 8704, DOI 10.17487/RFC8704, February 2020, 589 . 591 Authors' Addresses 593 Dan Li 594 Tsinghua 595 Beijing 596 China 598 Email: tolidan@tsinghua.edu.cn 600 Jianping Wu 601 Tsinghua 602 Beijing 603 China 605 Email: jianping@cernet.edu.cn 606 Yunan Gu 607 Huawei 608 Beijing 609 China 611 Email: guyunan@huawei.com 613 Lancheng Qin 614 Tsinghua 615 Beijing 616 China 618 Email: qlc19@mails.tsinghua.edu.cn 620 Tao Lin 621 H3C 622 Beijing 623 China 625 Email: lintao@h3c.com