idnits 2.17.00 (12 Aug 2021) /tmp/idnits21944/draft-li-sav-gap-analysis-01.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], [RFC5210], [RFC3704]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (11 January 2022) is 123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AS5' is mentioned on line 327, but not defined == Missing Reference: 'AS3' is mentioned on line 329, but not defined == Missing Reference: 'AS1' is mentioned on line 334, but not defined == Missing Reference: 'AS2' is mentioned on line 334, but not defined Summary: 2 errors (**), 0 flaws (~~), 7 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 University 5 Expires: 15 July 2022 M. Huang 6 Huawei 7 L. Qin 8 Tsinghua University 9 N. Geng 10 Huawei 11 11 January 2022 13 Source Address Validation: Use Cases and Gap Analysis 14 draft-li-sav-gap-analysis-01 16 Abstract 18 This document identifies the importance and use cases of source 19 address validation (SAV) at both intra-domain level and inter-domain 20 level (see [RFC5210]). Existing intra-domain and inter-domain SAV 21 mechanisms, either Ingress ACL filtering [RFC2827], unicast Reverse 22 Path Forwarding (uRPF) [RFC3704], or Enhanced Feasible-Path uRPF 23 (EFP-uRPF) [RFC8704] has limitations in scalability or accuracy. 24 This document provides gap analysis of the existing SAV mechanisms. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 8174 [RFC8174]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 15 July 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Use Case 1: Intra-domain SAV . . . . . . . . . . . . . . 5 69 3.2. Use Case 2: Inter-domain SAV . . . . . . . . . . . . . . 6 70 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Existing Intra-domain SAV mechanisms . . . . . . . . . . 6 72 4.2. Existing Inter-domain SAV mechanisms . . . . . . . . . . 7 73 5. SAV Requirements . . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 Source Address Validation (SAV) is important for defending against 83 source address forgery attacks and accurately tracing back to the 84 attackers. Considering that the Internet is extremely large and 85 complex, it is very difficult to solve the source address spoofing 86 problem at a single "level" or through a single SAV mechanism. On 87 the one hand, it is unrealistic to require all networks to deploy a 88 single SAV mechanism. On the other hand, the failure of a single SAV 89 mechanism will completely disable SAV. 91 To address the issue, Source Address Validation Architecture (SAVA) 92 was proposed [RFC5210]. According to the operating feature of the 93 Internet, SAVA presents a hierarchical architecture which carries out 94 source IP address validation at three checking levels, i.e., access 95 network, intra-domain, and inter-domain. Different levels provide 96 different granularities of source IP address authenticity. In 97 contrast to the single-level/point model, SAVA allows incremental 98 deployment of SAV mechanisms while keeps effective because of its 99 multiple-fence design. So, enhancing the source IP address validity 100 in all the three checking levels is of high importance. Furthermore, 101 one or more independent and loosely-coupled SAV mechanisms can 102 coexist and cooperate under SAVA, which is friendly to different 103 users (e.g., providers) with different policies or considerations. 104 Obviously, the quality of SAV mechanisms for their target checking 105 levels is key to the performance of SAV. 107 There are many SAV mechanisms for different checking levels. For the 108 access network level, Source Address Validation Improvement (SAVI) 109 was proposed to force each host to use legitimate source IP 110 address[RFC7039]. SAVI acts as a purely network-based solution 111 without special dependencies on hosts. It dynamically binds each 112 legitimate IP address to a specific port/MAC address and verifies 113 each packet's source address through the binding relationship. One 114 of the most attractive features of SAVI is that it supports the 115 maximally fine granularity of individual IP addresses, which previous 116 ingress filtering mechanisms cannot provide. 118 At the intra-domain level, static Access Control List (ACL) is a 119 typical solution of SAV. Operators can configure some matching rules 120 to specify which kind of packets are acceptable (or unacceptable). 121 The information of ACL should be updated manually so as to keep 122 consistent with the newest filtering criteria, which inevitably 123 limits the flexibility and accuracy of SAV. Strict unicast Reverse 124 Path Forwarding (uRPF) [RFC3704] is another solution suitable to 125 intra-domain. Routers deploying strict uRPF accept a data packet 126 only when i) the local FIB contains a prefix encompassing the 127 packet's source address and ii) the corresponding forwarding action 128 for the prefix matches the packet's incoming interface. Otherwise, 129 the packet will be dropped. However, in the scenarios (e.g., 130 multihoming cases) where data packets are under asymmetric routing, 131 strict uRPF often improperly blocks legitimate traffic. 133 At the inter-domain level, a combination of Enhanced Feasible-Path 134 uRPF (EFP-uRPF) and loose uRPF is recommended 135 in[RFC8704].Particularly, EFP-uRPF is suggested to be applied on 136 customer interfaces. EPF-uRPF on an AS can prevent its customers 137 from spoofing its upstream ASes' source addresses but fails in the 138 case of two customers spoofing each other. On lateral peer 139 interfaces and transit provider interfaces, loose uRPF [RFC3704] is 140 taken. The routers deploying loose uRPF accept any packets whose 141 source addresses appear in the local FIB tables. Due to the loss of 142 directionality, loose uRPF often improperly permits spoofed traffic. 144 To summarize, given that it is impossible to deploy SAVI on every 145 access network in the Internet, the "fences" at intra- and inter- 146 domain levels are very important for filtering source address forgery 147 packets that are let go by access networks. However, there exist 148 some instinctive drawbacks in the existing SAV mechanisms designed 149 for both the intra- and inter-domain levels, which leads to 150 inevitable improper permit or improper block problems. A more 151 complete SAV mechanism is required for both intra- and inter-domain 152 levels. 154 This document identifies the use cases of intra- and inter-domain 155 SAVs. These cases will help analyze the instinctive drawbacks of the 156 existing SAV mechanisms. After that, some SAV requirments will be 157 presented. 159 2. Terminology 161 EAST-WEST traffic denotes the traffic originated and terminated 162 within an AS. Intra-domain SAV aims to check EAST-WEST traffic and 163 prevents hosts/routers from spoofing other source IP blocks in the 164 same AS. 166 NORTH-SOUTH traffic denotes the traffic arriving from an external AS. 167 Particularly, the traffic arriving from the customer AS is Northward 168 traffic. The traffic received from the provider/peer AS is Southward 169 traffic. Inter-domain SAV aims to verify the authenticity of the 170 source address of NORTH-SOUTH traffic. 172 3. Use Cases 174 Figure 1 illustrates the use cases of SAV in both intra- and inter- 175 domain levels. AS1-AS5 belong to the same customer cone, and AS1 is 176 the stub AS. The topology of AS2 is presented while other ASes' 177 inner structures are hidden for brevity. 179 +---------------------+ 180 | AS5 | 181 +-/\---------------/\-+ 182 / \ 183 / \ 184 +-------------------/----------+ \ 185 | AS2 +----------+ | \ 186 | | Router 4 | | +------------+ 187 | +----------+ | | AS4 |--P1'' 188 | / \ | +-----/\-----+ 189 | +----------+ +----------+ | | 190 | | Router 2 |----| Router 3 | | | 191 | +----------+ +----------+ | | 192 | | \ / | | +------------+ 193 | P1' +----------+ P1 | | AS3 | 194 | | Router 1 | | +-----/\-----+ 195 | +----------+ | / 196 +------------------\-----------+ / 197 \ / 198 \ / 199 +-----------------------+ 200 | AS1 | 201 +-----------------------+ 202 P1 is the source IP address prefix of Router3. 203 P1' is the spoofed P1 by Router2 located in the same AS as Router3. 204 P1" is the spoofed P1 by Routers located in another AS, i.e., AS4. 206 Figure 1: Illustration of the use cases of SAV in both intra- 207 and inter-domain levels 209 3.1. Use Case 1: Intra-domain SAV 211 In some scenarios especially very large ASes, hosts/routers in the 212 same AS may spoof each other's IP addresses. In Figure 1, Router2 213 spoofs P1 that originates from Router3. With Intra-domain SAV, EAST- 214 WEST traffic can be checked, and source address spoofing attacks can 215 be prevented. In the figure, Router1, Router3, and Router4 will drop 216 the packets with P1' while accept those with P1, when they deploy 217 Intra-domain SAV mechanisms. Overall, Intra-domain SAV can prevent 218 the source address spoofing from the same AS. 220 3.2. Use Case 2: Inter-domain SAV 222 In Figure 1, AS4 spoofs AS2's IP address prefix, i.e., P1 originated 223 from Router3. AS5 will receive the Northward traffic from AS2 and 224 AS4 with legitimate and spoofed IP addresses, respectively. An SAV 225 mechanism is necessary for AS5 to drop the illegal traffic. From the 226 view point of Southward traffic, AS1 may also receive spoofed traffic 227 from AS3 (if AS3 accepts the data packets with source prefix P1"). 228 So, the deployment of SAV on AS1 is also important. Overall, Inter- 229 domain SAV is necessary and can improve the confidence of the source 230 IP address validity among ASes. 232 4. Gap Analysis 234 High accuracy is the basic requirement of any intra- or inter-domain 235 SAV mechanism. For any SAV mechanism, improper block problems must 236 be avoided because legitimate traffic must not be influenced. On 237 that basis, SAV should also reduce improper permit problems as much 238 as possible. However, existing SAV mechanisms can not well meet 239 these requirements. 241 4.1. Existing Intra-domain SAV mechanisms 243 Operators can configure static ACLs on border routers to validate 244 source addresses. The main drawback of ACL-based SAV is the high 245 operational overhead. Limited application scenarios make the ACL- 246 based method unable to do sufficient SAV on EAST-WEST traffic. 248 Strict uRPF can generate SAV tables automatically, but it also has 249 limited application scenarios. Figure 2 illustrates an intra-domain 250 scenario. In the scenario, AS1 runs strict uRPF. An access network 251 having IP address prefix 10.0.0.0/15 is attached to two border 252 routers (Router1 and Router2) of AS1. Due to customer's policy, it 253 advertises 10.0.0.0/16 to Router1 and 10.1.0.0/16 to Router2. Then, 254 Router1 and Router2 will advertise the learned IP address prefixes to 255 other routers in AS1 through intra-domain routing protocols such as 256 OSPF and IS-IS. 258 Although customer only advertises 10.0.0.0/16 to Router1, it may send 259 packets with source IP addresses belonging to 10.1.0.0/16 to Router1 260 due to load balancing requirements. Suppose the destination node is 261 Router5. Then the path to destination is 262 Customer->Router1->Router3->Router5, while the reverse path is 263 Router5->Router4->Router2->Customer. The round trip routing path is 264 asymmetric, which cannot be dealt with well by strict uRPF. 266 Specifically speaking, strict uRPF is faced with improper block 267 problems under asymmetric routing scenarios. When Router1/Router3 268 runs strict uRPF, it learns SAV rules that packets with source 269 address prefix of 10.0.0.0/16 must enter the router on interface '#'. 270 When the packets with source addresses of 10.1.0.0/16 arrive, they 271 will be dropped, which results in improperly blocking legitimate 272 traffic. Similarly, when strict uRPF is deployed on Router2, the 273 improper block problem still exists. 275 +-----------------------------------+ 276 | AS1 +----------+ | 277 | | Router 5 | | 278 | +----------+ | 279 | / \ | 280 | / \ | 281 | +----------+ +----------+ | 282 | | Router 3 |------| Router 4 | | 283 | +----#-----+ +----------+ | 284 | | | | 285 | | | | 286 | +----------+ +----------+ | 287 | | Router 1 | | Router 2 | | 288 | +----#-----+ +----------+ | 289 | \ / | 290 +--------\---------------/----------+ 291 \ / 292 10.0.0.0/16 10.1.0.0/16 293 \ / 294 +-------------------+ 295 | access network |----10.0.0.0/15 296 +-------------------+ 297 Figure 2: An intra-domain scenario 299 4.2. Existing Inter-domain SAV mechanisms 301 The most popular inter-domain SAV is suggested by [RFC8704], which 302 combines EFP-uRPF algorithm B and loose uRPF. In particular, EFP- 303 uRPF algorithm B is for Northward traffic validation. It sacrifices 304 the directionality of customer interfaces for reducing improper 305 permit cases. Loose uRPF is for validating Southward traffic on 306 lateral peer and transit provider interfaces. It sacrifices 307 directionality of Southward traffic completely. Such a combined 308 method sacrificing directionality will leads to improper permit 309 problems sometimes. 311 Figure 3 illustrates a common inter-domain scenario where the above 312 inter-domain SAV method will fail. In the figure, there are two 313 customer ASes, i.e., AS1 and AS2. Both of them are attached to a 314 provider AS, i.e., AS4. AS4 has a lateral peer and a provider, i.e., 315 AS3 and AS5. Particularly, AS1 has IP address prefix P1 and 316 advertises it to AS4. IP address prefix P2 is allocated to AS2 and 317 is also advertised to AS4. AS3 has IP address prefix P3 and AS5 has 318 IP address prefix P5. P3 and P5 are also advertised to AS4 through 319 BGP. All arrows represent BGP advtisements. Assume AS4 deploys 320 inter-domain SAV policies, i.e., a combination of EFP-uRPF algorithm 321 B and loose uRPF. 323 +-----------------+ 324 | AS5 (provider) +---+P5 325 +--------+--------+ 326 | 327 | P5[AS5] 328 P3 | 329 +----------+ [AS3] +-------\/--------+ 330 |AS3 (peer)+------>+ AS4 | 331 +-----+----+ +-+/\+-------+/\+-+ 332 | / \ 333 + / \ 334 P3 P1[AS1]/ \ P2[AS2] 335 / \ 336 / \ 337 +----------------+ +----------------+ 338 P1+---+ AS1 (customer) | | AS2 (customer) +---+P2 339 +----------------+ +----------------+ 341 Figure 3: An inter-domain scenario 343 For Northward traffic, AS4 applies EFP-uRPF. Under EFP-uRPF, AS4 344 will generate SAV rules considering P1 and P2 are legitimate on both 345 the two customer interfaces. When AS1 spoofs IP address prefix P2 of 346 AS2, the malicious Northward traffic cannot be filtered by AS4. The 347 same is true when AS2 forges P1 of AS1. That is to say, EPF-uRPF 348 cannot prevent source address spoofing among customers even though it 349 only focus on Northward traffic. 351 For Southward traffic, AS4 deploys loose uRPF for the interfaces of 352 AS3 and AS5. It will learn that the packets with source addresses of 353 P3 or P5 can be accepted without validating the specific arrival 354 interface. Since loose uRPF loses directionality completely, it 355 obviously will fail in dealing with the source address spoofing 356 between its lateral peer and provider, i.e., AS3 and AS5. 358 5. SAV Requirements 360 High accuracy, i.e. avioding improper block problems while trying 361 best to reduce improper permit problems, is the basic requirement of 362 an ideal SAV mechanism. As described above, existing SAV mechanisms 363 cannot meet this requirement. The root cause of their limitations is 364 that they all achieve SAV based on local forwarding information base 365 (FIB) or routing information base (RIB), which may not match the real 366 forwarding direction from the source. In order to guarantee the 367 accuracy, SAV should follow the real data-plane forwarding path. To 368 solve this problem and provide accurate SAV for arbitrary network 369 scenarios, it is required to exchange/explore/probe the fowarding- 370 path information among routers/ASes. In other words, network-wide 371 protocols should be considered. 373 The network-wide protocols should also consider some practical 374 issues: 376 * High scalability. The protocols should not induce much overhead 377 (e.g., bandwidth cost of path probing). Fast convergence under 378 environment changes is also important for improving the 379 scalability in different scales of networks. 381 * High deployability. A strategy of incremental deployment needs to 382 be considered. If some routers/ASes do not support the new 383 protocols, improper block should be avoided. 385 * High security. The protocols should include mechanisms to 386 guarantee the integrity of protocol packets. Security risks such 387 as Man-in-the-Middle Attack should be avoided. 389 6. Security Considerations 391 TBD 393 7. Contributors 395 TBD 397 8. Acknowledgments 399 TBD 401 9. Normative References 403 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 404 Defeating Denial of Service Attacks which employ IP Source 405 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 406 May 2000, . 408 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 409 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 410 2004, . 412 [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, 413 "A Source Address Validation Architecture (SAVA) Testbed 414 and Deployment Experience", RFC 5210, 415 DOI 10.17487/RFC5210, June 2008, 416 . 418 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 419 "Source Address Validation Improvement (SAVI) Framework", 420 RFC 7039, DOI 10.17487/RFC7039, October 2013, 421 . 423 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 424 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 425 May 2017, . 427 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 428 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 429 RFC 8704, DOI 10.17487/RFC8704, February 2020, 430 . 432 Authors' Addresses 434 Dan Li 435 Tsinghua University 436 Beijing 437 China 439 Email: tolidan@tsinghua.edu.cn 441 Jianping Wu 442 Tsinghua University 443 Beijing 444 China 446 Email: jianping@cernet.edu.cn 447 Mingqing Huang 448 Huawei 449 Beijing 450 China 452 Email: huangmingqing@huawei.com 454 Lancheng Qin 455 Tsinghua University 456 Beijing 457 China 459 Email: qlc19@mails.tsinghua.edu.cn 461 Nan Geng 462 Huawei 463 Beijing 464 China 466 Email: gengnan@huawei.com