idnits 2.17.1 draft-bi-savi-problem-08.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 a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2014) is 3440 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI J. Bi 3 Internet-Draft B. Liu 4 Intended status: Informational Tsinghua Univ. 5 Expires: May 22, 2015 November 18, 2014 7 Problem Statement of SAVI Beyond the First Hop 8 draft-bi-savi-problem-08 10 Abstract 12 IETF Source Address Validation Improvements (SAVI) working group is 13 chartered for source address validation within the first hop from the 14 end hosts, i.e., preventing a node from spoofing the IP source 15 address of another node in the same IP link. However, since SAVI 16 requires the edge routers or switches to be upgraded, the deployment 17 of SAVI will need a long time. During this transition period, some 18 source address validation techniques beyond the first hop (SAVI-BF) 19 may be needed to complement SAVI and protect the networks from 20 spoofing based attacks. In this document, we first propose three 21 desired features of the SAVI-BF techniques. Then we analyze the 22 problems of the current SAVI-BF technique, ingress filtering. 23 Finally, we discuss the directions that we can explore to improve 24 SAVI-BF. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 22, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Desired Features of SAVI-BF Techniques . . . . . . . . . . . 3 74 2.1. High Deployment Incentives . . . . . . . . . . . . . . . 3 75 2.2. Low Operational Risks . . . . . . . . . . . . . . . . . . 3 76 2.3. Low Cost . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Problems of Ingress Filtering . . . . . . . . . . . . . . . . 4 78 3.1. IAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3.2. Strict/feasible RPF . . . . . . . . . . . . . . . . . . . 6 80 3.3. Loose RPF* . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.4. Other Reasons . . . . . . . . . . . . . . . . . . . . . . 6 82 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. Path based Techniques . . . . . . . . . . . . . . . . . . 7 84 4.2. End-to-end based Techniques . . . . . . . . . . . . . . . 7 85 4.3. Non-technical Proposals . . . . . . . . . . . . . . . . . 8 86 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 87 6. Informative References . . . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 IETF Source Address Validation Improvements (SAVI) working group is 93 chartered for source address validation within the first hop from the 94 end hosts, so as to prevent a node from spoofing the IP source 95 address of another node in the same IP link. However, since SAVI 96 requires the edge routers or switches to be upgraded, the deployment 97 of SAVI will need a long time. During this transition period, some 98 source address validation techniques beyond the first hop (SAVI-BF) 99 may be needed to complement SAVI, so as to protect the networks from 100 spoofing based attacks, which are prevalent DDoS attacks on the 101 current Internet [Ground-Truth] [ARBOR-2010] [NANOG-Helpless] 102 [DrDoS-300Gbps]. 104 In this document, we first propose three desired features of SAVI-BF 105 techniques. The first desired feature is high deployment incentives, 106 i.e., by deploying a technique, an ISP should significantly increase 107 its ability to protect its network from spoofing based attacks. The 108 second one is low operational risks. If a technique may improperly 109 drop legitimate packets (so called false positives), it introduces 110 new risks to the network operation and management. It is desired 111 that the false positives (FP) is as low as possible. The third one 112 low cost. It is desired that the technique requires minimum 113 deployment investment and operational cost. 115 We evaluate ingress filtering [BCP38] [BCP84], the best current 116 practice in for SAVI-BF, against these three features. Recent 117 measurement shows that, the deployment of ingress filtering has not 118 been improved over four years because the ISPs do not have incentives 119 to deploy it [Efficacy], and sophisticated attackers exploit the 120 spoofable networks to launch attacks. We discuss the reasons why 121 ingress filtering is still insufficiently applied by the ISPs despite 122 that it has long been available in modern routers. 124 Finally, we discuss the directions that we can explore to improve 125 SAVI-BF. We briefly survey two categories of SAVI-BF proposals, the 126 path based techniques and the end-to-end based techniques. We 127 discuss their requirements, advantages and disadvantages. 129 2. Desired Features of SAVI-BF Techniques 131 2.1. High Deployment Incentives 133 To motivate an ISP to deploy a technique, it is desirable that the 134 technique can generate additional benefit for the ISP. In terms of a 135 SAVI-BF technique, it should provide the ISP with additional 136 protection from spoofing based attacks. Specifically, it should 137 significantly decrease the volume of the spoofing based attacks 138 targeting the ISP, or the number of networks where these attacks can 139 be successfully launched, or the number of source addresses or 140 destination addresses that can be used in these attacks. 142 2.2. Low Operational Risks 143 If a technique may improperly drop legitimate packets, so called 144 false positives (FP), it introduces new operational risks. 145 Apparently, it is desired that the FP is as low as possible. The 146 higher the FP, the more limited its application scope. For example, 147 if the attack is not very severe, the network administrator would not 148 apply a technique with high FP, since its operation risks may even 149 surpass the loss caused by the attack. 151 2.3. Low Cost 153 It is desired that the technique requires minimum investment on the 154 device and system upgrading. It should also adapt to network 155 dynamics rather than require manual intervention, which is costly, 156 slow, and often the source of errors (misconfiguration). 158 3. Problems of Ingress Filtering 160 Ingress filtering is the best current practice for SAVI-BF. Ingress 161 filtering was proposed in 2000 [BCP38] , and updated in 2004 [BCP84]. 162 Ingress access lists (IALs) and unicast reverse path forwarding 163 (uRPF) are two general ways to implement ingress filtering. An IAL 164 is a filter that checks the source address of every packet received 165 on a network interface against a list of acceptable prefixes, 166 dropping any packet that does not match the filter. IALs are 167 typically maintained manually. Upon network dynamics (topology 168 change or routing change), the IALs should be updated accordingly to 169 avoid dropping legitimate packets. uRPF is an automated tool which 170 can adapt with the network dynamics. On the receipt of a packet, 171 uRPF checks its source address against the forwarding table or 172 routing table for validation. uRPF has four variants, strict RPF, 173 feasible RPF, loose RPF and loose RPF ignoring default routes. 174 Readers are referred to [BCP84] for the details of these variants. 176 Today, many modern routers are capable of ingress filtering. Many 177 network administrators have turned on uRPF on their routers or been 178 actively maintaining IALs to filter spoofing traffic. The fraction 179 of networks where spoofing is possible is significantly limited 180 [MIT-Spoofer]. However, as shown by the recent measurement, the 181 deployment of ingress filtering has not been improved over four 182 years. Sophisticated attackers can still exploit the networks where 183 spoofing is possible to launch spoofing based attacks, and IP 184 spoofing remains a viable attack vector on the current Internet 185 [Efficacy]. 187 In this section, we evaluate ingress filtering against the desired 188 features, and analyze the reasons why ingress filtering is not 189 sufficiently deployed, and why its deployment has not been improved 190 over years. We classify the five variants of ingress filtering (IAL 191 and four variants of uRPF) into three categories according to their 192 technical similarities, i.e., IALs, strict/feasible RPF, and loose 193 RPF* (including loose RPF and loose RPF ignoring default routes). 194 The evaluation results are summarized in Table 1, which will be 195 explained in detail in the following subsections. 197 +---------------------+-----------+------+------+ 198 | Techniques | Incentive | Risk | Cost | 199 +---------------------+-----------+------+------+ 200 | IAL | low | low | low | 201 | - | - | - | - | 202 | Strict/feasible RPF | high | high | low | 203 | - | - | - | - | 204 | Loose RPF* | low | low | low | 205 +---------------------+-----------+------+------+ 207 Table 1: Evaluation of Ingress Filtering 209 3.1. IAL 211 IAL can be applied at network border routers and enforced on outbound 212 packets. All the outbound packets whose source addresses do not 213 belong to the local network are identifed as spoofed. Since it only 214 filters outbound packets, and cannot protect the local network from 215 receiving spoofing packets, it provides little deployment incentives. 216 When IAL is enforced on inbound packets, there are two typical 217 scenarios. In the first scenario, it is applied on the routers' 218 ingress interface connecting a stub network. In this case, the 219 source address space of the stub network can be configured on this 220 interface, and all inbound packets whose source addresses fall out of 221 this address space are identified as spoofed. Since the address 222 space size of directly connected stub networks is very small compared 223 to the entire routable address space, the effectiveness is low. In 224 the second scenario, the directly connected network is not stub, and 225 thus the valid address space of inbound packets is hard to determine. 226 In this case, IAL can only safely drop the inbound packets whose 227 source addresses belong to the local network. It is very ineffective 228 since the address space size of the local network very small compared 229 to the entire routable address space. To summize, IAL provides low 230 deployment incentives in all cases. If well maintained, false 231 positives can also be avoided. IAL can be implemented using the 232 existing functions on routers (access control lists, ACLs), and thus 233 do not require additional investment. Overall, the deployment cost 234 is low except in the "stub-network" scenario, where the address space 235 of all stubs need to be carefully maintained, which may require heavy 236 manual configuration if there are many directly connected stub 237 networks. 239 3.2. Strict/feasible RPF 241 Strict and feasible RPF can adapt themselves to the routing dynamics 242 and determine the incoming directions of source prefixes 243 automatically. They are more effective than IAL in detecting and 244 filtering spoofing traffic, and thus provide higher deployment 245 incentives to the ISPs. However, they often drop legitimate packets 246 under routing asymmetry, which is very prevalent with the existence 247 of local routing policies, multi-homing and traffic engineering. 248 This makes strict and feasible very risky [NANOG-Risk], and hence the 249 operation needs to be very careful. Feasible RPF has lower FP than 250 strict RPF, since it can apply multiple interfaces as acceptable 251 incoming directions for a source prefix. But feasible RPF cannot 252 avoid all FP in practice, since currently there is no practical way 253 to generate and configure all possible incoming directions in the 254 routers. For example, in a link-state routing environment (IS-IS or 255 OSPF), equal-cost multi-path (ECMP) [ECMP] is often used to generate 256 the multiple acceptable incoming directions. However, in practice, 257 there can be many (tens of) ECMPs for a prefix, but the 258 implementation of a router can only store several (e.g., 4 or 8) of 259 them. Thus the ECMPs for the prefix installed in the forwarding 260 table may be different in different routers, which eventually causes 261 the FP of feasible RPF. And in BGP, the directions where BGP 262 announcements for a source address prefix have been received can be 263 considered as acceptable incoming directions [IDPF]. However, an ISP 264 may choose not to announce a prefix via a path but still send traffic 265 through it due to its local routing policy. In this case, feasible 266 RPF also causes FP. The basic function of strict and feasible RPF is 267 supported in most modern routers. So deploying them doesn't require 268 investment on upgrading devices. 270 3.3. Loose RPF* 272 Instead of validating the incoming direction of a source address, 273 loose RPF* only checks the existence of the source address in the 274 forwarding table. Loose RPF* is only useful for filtering Martian 275 addresses and unroutable addresses. However, sophisticated attackers 276 can evade loose RPF* checking by simply using routable source 277 addresses. Thus the incentive to deploy loose RPF is low. On the 278 other hand, its operational risk is also low. Loose RPF* is also 279 available in most modern routers, making it cheap to deploy. 281 3.4. Other Reasons 283 There are other reasons why the deployment of ingress filtering 284 hasn't been improved in four years. First, although most modern 285 routers are capable of ingress filtering, some legacy routers are 286 incapable [NANOG-Equipment]. Hence, even at the locations where no 287 risk exists (e.g. stub or single-homed networks), ingress filtering 288 may not be applied. Another reason is called inertia. Since ingress 289 filtering is not enabled on routers by default, some network 290 administrators just won't bother to turn it on 291 [NANOG-PowerOfDefaults]. 293 4. Discussion 295 In this section, we discuss the directions that we can explore to 296 improve SAVI-BF. We briefly survey two categories of SAVI-BF 297 proposals, the path based techniques and the end-to-end based 298 techniques. We discuss their requirements, advantages and 299 disadvantages. We only focus on the techniques that are implemented 300 on the routers. The techniques implemented on end hosts, such as 301 [IPSec], [HCF] and [IP-Puzzles], are not covered here. 303 4.1. Path based Techniques 305 The path based techniques essentially require that a router R knows 306 the forwarding paths that each source prefix S uses toward its 307 destinations, and subsequently knows the incoming directions/ 308 interfaces of S. Sometimes, this information is available to R. For 309 example, in a pure link-state routing protocol environment (e.g., IS- 310 IS, OSPF), all nodes have the same view of the network. Thus, R can 311 compute the paths from S to all destinations, and then infer the 312 incoming directions of S. One exception is that, when there are 313 multiple equally best paths, R may not determine which one S will 314 use. On the other hand, if a distance-vector (e.g., RIP) or a path- 315 vector (BGP) routing protocol is used, it is even harder for R to 316 determine the paths of S, since the sufficient routing information is 317 missed. [SAVE] and [IDPF] are tow proposals which validate source 318 addresses by inferring their forwarding paths. 320 4.2. End-to-end based Techniques 321 There are, however, other proposals that don't rely on path 322 information. We call them end-to-end based techniques. For example, 323 [SPM] associates each source prefix (indeed, source AS number) with a 324 key. S, an SPM-enabled AS, will tag the key into outbound packets 325 toward R at its border routers. And R verifies the keys of the 326 inbound packets whose source addresses belong to S at its border 327 routers. The routers will drop a packet if the key is incorrect. 328 Thus, R manages to validate the source addresses of S without knowing 329 its forwarding paths. The end-to-end based the techniques typically 330 need the cooperation between the source and the verification nodes, 331 and require particular tags be carried in the data packets. Further 332 more, even the end-to-end based techniques require to distinguish 333 inbound traffic and outbound traffic, which is not completely path- 334 independent. 336 4.3. Non-technical Proposals 338 There are also proposals which formulate source address validation as 339 an economic problem [FaaS], or suggest that laws and governance 340 should be enforced. These directions, however, may be out of the 341 scope of IETF. 343 5. Acknowledgment 345 The authors would like to thank Fred Baker and Joel M. Halpern for 346 their comments. 348 This document was generated using the xml2rfc tool. 350 6. Informative References 352 [ARBOR-2010] 353 Dobbins, R. and C. Morales, "Network Infrastructure 354 Security Report", February 2010. 356 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 357 Defeating Denial of Service Attacks which employ IP Source 358 Address Spoofing", RFC 2827, BCP 38, May 2000. 360 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 361 Networks", RFC 3704, BCP 84, March 2004. 363 [DrDoS-300Gbps] 364 Prince, M., "The DDoS That Almost Broke the Internet", 365 March 2013. 367 [ECMP] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 368 Multicast Next-Hop Selection", RFC 2991, November 2000. 370 [Efficacy] 371 Beverly, R., Berger, A., Hyun, Y., and k. claffy, 372 "Understanding the Efficacy of Deployed Internet Source 373 Address Validation Filtering", August 2009. 375 [FaaS] Liu, B., Bi, J., and X. Yang, "FaaS: Filtering IP Spoofing 376 Traffic as a Service", 2012. 378 [Ground-Truth] 379 Labovitz, C., "Botnets, DDoS and Ground-Truth", October 380 2010. 382 [HCF] Jin, C., Wang, H., and K. Shin, "Hop-count filtering: an 383 effective defense against spoofed DDoS traffic", 2003. 385 [IDPF] Duan, Z., Yuan, X., and J. Ch, "Controlling IP Spoofing 386 Through Inter-Domain Packet Filters", 2008. 388 [IP-Puzzles] 389 Feng, W., Feng, W., and A. Luu, "The Design and 390 Implementation of Network Puzzles", 2005. 392 [IPSec] Kent, S. and K. Seo, "Security Architecture for the 393 Internet Protocol", RFC 4301, December 2005. 395 [MIT-Spoofer] 396 Beverly, R., "Spoofer Project", January 2012, 397 . 399 [NANOG-Equipment] 400 Bicknell, L., "BCP38 Deployment", March 2012, . 403 [NANOG-Helpless] 404 Bulk, F., "Are we really this helpless? (Re: isprime DOS 405 in progress)", January 2009, . 408 [NANOG-PowerOfDefaults] 409 Donelan, S., "BCP38 Deployment", March 2012, . 412 [NANOG-Risk] 413 Gilmore, P., "BCP38 Deployment", March 2012, . 416 [SAVE] Li, J., Mirkovic, J., Wang, M., Reiher, P., and L. Zhang, 417 "SAVE: Source Address Validity Enforcement Protocol", 418 2002. 420 [SPM] Anat, A. and H. Hanoch, "Spoofing Prevention Method", 421 March 2005. 423 Authors' Addresses 425 Jun Bi 426 Tsinghua University 427 Network Research Center, Tsinghua University 428 Beijing 100084 429 China 431 Email: junbi@tsinghua.edu.cn 433 Bingyang Liu 434 Tsinghua University 435 Network Research Center, Tsinghua University 436 Beijing 100084 437 China 439 Email: liubingyang@tsinghua.edu.cn