SAVI J. Bi Internet-Draft B. Liu Intended status: Informational Tsinghua Univ. Expires: August 2, 2012 January 30, 2012 Problem Statement of SAVI Beyond the First Hop draft-bi-savi-problem-01 Abstract IETF Source Address Validation Improvements (SAVI) working group is chartered for source address validation within the first hop from the end hosts, i.e. preventing a node from spoofing the IP source address of another node in the same IP link. For source address validation beyond the first hop (SAVI-BF), Ingress Filtering [BCP38]/[BCP84] is the best current practice. However Ingress Filtering may drop legitimate packets (false positive) or fail to recognize spoofing packets (false negative) in case of asymmetric routing, which is not rare under SAVI-BF scenario. This document states the possible scenarios in which Ingress Filtering may have problems (false positive or false negative), and lists five causes of the problems. These fives causes, we believe, are the challeges that need be conquered by SAVI-BF solutions (including possible improved version of Ingress Filtering). We also observe that the incentive for Internet Service Providers (ISP) to deploy SAVI-BF differs from intra-domain scenario to inter-domain scenario, and incenting ISPs to deploy inter-domain SAVI is more challenging. Although not intend to provide any SAVI-BF solution in this document, we discuss the philosophy in designing a SAVI-BF mechanism. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Bi & Liu Expires August 2, 2012 [Page 1] Internet-Draft SAVI Problem Beyond First Hop January 2012 This Internet-Draft will expire on August 2, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Bi & Liu Expires August 2, 2012 [Page 2] Internet-Draft SAVI Problem Beyond First Hop January 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problems of Ingress Filtering . . . . . . . . . . . . . . . . 5 2.1. Ingress Access Lists . . . . . . . . . . . . . . . . . . . 5 2.2. Strict Reverse Path Forwarding . . . . . . . . . . . . . . 5 2.3. Feasible Reverse Path Forwarding . . . . . . . . . . . . . 7 2.4. Loose Reverse Path Forwarding . . . . . . . . . . . . . . 8 2.5. Loose Reverse Path Forwarding Ignoring Default Routes . . 9 3. Challenges to SAVI-BF . . . . . . . . . . . . . . . . . . . . 9 3.1. Asymmetric Link Metrics . . . . . . . . . . . . . . . . . 9 3.2. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Static Routing and Local Routing Policy . . . . . . . . . 10 3.4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Inter-domain Route Aggregation . . . . . . . . . . . . . . 11 4. Deployment Incentive . . . . . . . . . . . . . . . . . . . . . 11 4.1. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . . 11 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Distributing Routing Information or Routing Decisions . . 13 5.2. Distributed or Centralized . . . . . . . . . . . . . . . . 13 5.3. Routing Protocol Dependent or Independent . . . . . . . . 13 5.4. Deployment Incentive or Regulation . . . . . . . . . . . . 14 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Bi & Liu Expires August 2, 2012 [Page 3] Internet-Draft SAVI Problem Beyond First Hop January 2012 1. Introduction Ingress Filtering [BCP38]/[BCP84] is now the only practical source address validation technique beyond the frist hop from the end hosts. According to the report [ARBOR] by ARBOR Networks in 2009, of the 132 network operators as the survey respondents, only about 35% deployed [BCP38] at dedicated customer edge, about 35% deployed it at broadband edge, and about 45% deployed it at peering edge. And the measurement by MIT ANA Spoofer project [Spoofer] shows that 31% of the test clients were able to successfully spoof an arbitrary, routable source address, while 77% of clients otherwise unable to spoof could forge an address within their own /24 subnetwork, and no mitigation improvement against spoofing over four years of measurement. The difficulties ISP met in deploying Ingress Filtering implies the intrinsic problems of Reverse Path Forwarding (RPF). Detailed in [BCP84], Ingress Filtering has five ways of implementation. The first one is Ingress Access Lists, which are typically manually maintained and thus difficult to be practical in dynamic environment. Strict Reverse Path Forwarding (Strict RPF) and Feasible Path Reverse Path Forwarding (Feasible RPF) take advantage of the Reverse Path Forwarding technique, and they share the same flaw with RPF, i.e. droping legitimate packets (false positive) under asymmetric routing. Loose Reverse Path Forwarding (Loose RPF) and Loose Reverse Path Forwarding Ignoring Default Routes (Loose RPF Ignoring Default Routes) check the existence of a route instead of where the route points to. These two ways of implementation, of course, have lower false positive, but they in a lot of cases cannot recognize spoofing packets (false negative) and thus are known as very inefficient. The reason of the problems of Ingress Filtering, is the lack of routing information, because the behavior of a SAVI-BF solution should adhere to the routing system. If the routing information on routers is asynchronous, a router may fail to predict the inbound direction of an incoming packet from other routers when the route is asymmetric. We list five causes that result in the routing information asynchrony, i.e. asymmetric link metrics, equal-cost multi-path (ECMP), static routing and local routing policy, fast reroute and inter-domain route aggregation. These causes, we believe, are the challeges that need be conquered by SAVI-BF solutions (including possible improved version of Ingress Filtering) to make the solutions more extensively practical. We also observe that, the incentive for Internet Service Providers (ISP) to deploy SAVI-BF differs from intra-domain scenario to inter- domain scenario. In the intra-domain scenario, an ISP may want to deploy SAVI-BF for better security, accountability and management. Bi & Liu Expires August 2, 2012 [Page 4] Internet-Draft SAVI Problem Beyond First Hop January 2012 In the inter-domain scenario, however, an ISP could not filter much inbound spoofing traffic unless the degree the autonomous system (AS) is high. And filtering outbound spoofing traffic only protects other ISPs (possibly competitors), not protecting itself. So incenting ISPs to deploy inter-domain SAVI-BF is much more challenging, in the sense that an ISP is a benefit unit in the Internet. This document is organized as follows. In Section 2, the problems of Ingress Filtering are stated. The challenges to SAVI-BF are discussed in Section 3. Incentives for ISPs to deploy SAVI-BF is discussed in Section 4. Discussion on philosophy of designing a SAVI-BF mechanism is provided in Section 5. 2. Problems of Ingress Filtering In this section, we examine each mode of Ingress Filtering, and explore possible practical problems. 2.1. Ingress Access Lists Ingress Access Lists are typically maintained manually, and it is only applicable where the number of prefix is small and the routing is stable over time. However, when dynamic routing protocols (e.g. BGP, OSPF, IS-IS and RIP) are in use, routing will oscillate in case of link failure, new link creation or reconfiguration. Thus Ingress Access Lists may filter out valid packets (false positive) or let spoofing packets pass (fase negative). 2.2. Strict Reverse Path Forwarding The procedure of Strict RPF is that the source address is looked up in the Forwarding Information Base (FIB) - and if the packet is received on the interface which would be used to forward the traffic to the source of the packet, it passes the check. Obviously if the route is asymmetric, Strict RPF will cause false positive. Unfortunately, asymmetric routing is not rare in intra-domain or inter-domain routing. Next, we list five causes of asymmetric routing. o Asymmetric Link Metrics: The metric of a link in the forth direction is different to that in the reverse direction. For example, in OSPF, IS-IS and EIGRP, the cost of a link in the reverse direction can be assigned a differet value than that in the forth direction. Hence the source and destination nodes may see different total cost on the same path. Therefore they may choose different best paths to each other, and then asymmetric routing occurs. In BGP, although the cost of an AS link is always Bi & Liu Expires August 2, 2012 [Page 5] Internet-Draft SAVI Problem Beyond First Hop January 2012 1, an AS can prepend its AS number in the BGP path multiple times (AS-Path Prepending, or ASPP [ASPP]) to tune the "link" cost. Thus the cost of a same path is evaluated differently from different direction, which causes asymmetry. RIP, however, doesn't allow asymmetric link metrics. The cost of every link is 1 (hop). o Equal-Cost Multi-Path (ECMP) [ECMP]: Even if there is no asymmetric link metric, the route can still be asymmetric because of the multiple equal-cost best paths. In this case, the source node and the destination node see same cost on every possible path, and they both have the same set of best paths toward each other, but they may choose different ones to use in the data plane (FIB). Thus the route can still be asymmetric. o Static Routing and Local Routing Policy: Besides the dynamic routing protocols, static routing and policy routing are also in use in many situations. For instance, static routing (default route as an extreme example) is often used in the intra-domain scenario for the purpose of traffic engineering or management. In the inter-domain scenario, policy routing is a way to implement local preference to reflect inter-domain economic relationship. And when there are multiple equally-good BGP routes, hot-potato routing is often used to select the one with the closest egress point based on the intra-domain path cost [Hot-Potato]. In the inter-domain routing, where the units are ASes, hot-potato routing is a local policy made inside an AS. Usually, static routing and local routing policy are used to select a route that is not a best route computed by dynamic routing protocols, or select one route from multiple best routes. Obviously, manipulating routing locally may cause routing asymmetry. Even worse, because static routes or local route policies are typically not spread to the network with routing protocols, other nodes on the network are not able to collect this information or predict it. o Fast Reroute [Fast-Reroute-MPLS]/[Fast-Reroute-Framework]: Fast reroute is a mechanism that provides protection against link or router failure by invoking locally determined repair paths. When fast reroute takes into effect, the paths between the source and the destination will become asymmetric temporarily. During this time, a valid packet may arrive a router from an unexpected direction, and be filtered improperly. o Inter-Domain Route Aggregation [Aggregation]: Route aggregation is often used in inter-domain routing to reduce the size, slows the growth, of the Internet routing table, and limit the route flaps in number, frequence and scope. However, route aggregation may cause inter-domain path asymmetry. For example, in the figure Bi & Liu Expires August 2, 2012 [Page 6] Internet-Draft SAVI Problem Beyond First Hop January 2012 below, we have four ASes S, D, P1 and P2. Consider that S is a multi-homed AS, and its two providers P1 and P2. S announces a prefix 10.0.0.0/22 to both P1 and P2. P1 aggregats, and announces only 10.0.0.0/19 to D. In contrast, P2 announces the original prefix 10.0.0.0/22 to D. Thus a piece of FIB of D is shown as the table below. Assuming that S prefers P1 to P2 as the next hop for destination D, and hence the AS path for a legitimate packet (s, d) would be "S -> P1 -> D". However, because routers always do longest prefix matching, D will select P2 as the next hop toward S, i.e. the path for (d, s) would be "D -> P2 -> S". Then the path is asymmetric. D ^ ^ 10.0.0.0/19 / \ 10.0.0.0/22 / \ P1 P2 ^ ^ 10.0.0.0/22 \ / 10.0.0.0/22 \ / S +-------------+----------+ | Prefix | Next Hop | +-------------+----------+ | 10.0.0.0/22 | P2 | | 10.0.0.0/19 | P1 | +-------------+----------+ FIB of D 2.3. Feasible Reverse Path Forwarding Feasible RPF extends Strict RPF by inserting alternative routes (if any) into FIB, instead of just inserting one best route. A well- known implementation of Feasible RPF is RPF check considering ECMP. ECMP installs multiple best routes into FIB. All the ECMP out- interfaces are considered valid as the in-interfaces of the given source address prefix. Feasible RPF doesn't solve all the problems causing routing asymmetry introduced in the "Strict RPF" subsection. Indeed, Feasible RPF only partially solves the "ECMP" problem. Ideally, Feasible RPF can store all ECMPs. However, in practice, there can be many (tens of) ECMPs for a prefix, but the implementation of routers can only store several (e.g. 4 or 8) of them. Then the ECMPs for the prefix installed in FIB may be different in different routers, which Bi & Liu Expires August 2, 2012 [Page 7] Internet-Draft SAVI Problem Beyond First Hop January 2012 eventually causes asymmetric routing and false positive. 2.4. Loose Reverse Path Forwarding Loose RPF is algorithmically similar to strict RPF, but differs in that it checks only for the existence of a route. The obvious drawback is that Loose RPF could be very inefficient, because any routable source prefix could be accpeted regardless of its incoming direction, which results in high false negative. In a more rigorous case, a slightly smarter attacker can use only routable source addresses to launch spoofing based attacks, and this can nullify the efficacy of Loose RPF completely. Even without "smarter attack", randomly selected source addresses have the probability higher than 50% to pass Loose RPF, because in the current Internet, more than 50% of the address span is routable [BGP-Table]. There are two variants of Loose RPF, depending on how to deal with default route (or 0.0.0.0/0). The first one treats default route as a normal route, so that any source prefix from any direction will be accepted with the presence of the default route. The second variant, in contrast, checks the direction of the default route, i.e. any source prefix from the direction where the default route points to is accepted, and the source prefixes coming from other directions are checked against the remaining FIB (FIB without default route). With the presence of default route, the first variant won't filter any source prefix, and thus doesn't have false positive. However, for the second variant, we reveal the scenario where it can cause false positive with the presence of default route. In the figure below, router S and D take advantage of static routing. The FIB of S and D is shown below. In this case, a packet (s, d) will be delivered via the path (S -> R2 -> D). However, according to the FIB of D, this packet is supposed to come from R1 if Loose RPF (second variant) is used by D. So this asymmetric path causes false positive. S 10.0.0.0/16 / \ / \ 10.1.0.0/16 R1 R2 10.2.0.0/16 \ / \ / D 10.3.0.0/16 Bi & Liu Expires August 2, 2012 [Page 8] Internet-Draft SAVI Problem Beyond First Hop January 2012 +-------------+----------+ | Prefix | Next Hop | +-------------+----------+ | 10.0.0.0/16 | local | | 10.1.0.0/16 | R1 | | 0.0.0.0/0 | R2 | +-------------+----------+ FIB of S +-------------+----------+ | Prefix | Next Hop | +-------------+----------+ | 10.3.0.0/16 | local | | 10.2.0.0/16 | R2 | | 0.0.0.0/0 | R1 | +-------------+----------+ FIB of D 2.5. Loose Reverse Path Forwarding Ignoring Default Routes The Loose RPF Ignoring Default Routes is similar to Loose RPF except that the default route is excluded, i.e. the source prefixes matching (in terms of longest prefix matching) the default route will be discarded. Therefore, the technique is mostly usable in scenarios where default routes are used only to catch traffic with bogus source addresses, with an extensive (or even full) list of explicit routes to cover legitimate traffic. If applied in other scenarios, this technique will cause false positive because of the routing asymmetry. 3. Challenges to SAVI-BF The reason of the problems of Ingress Filtering is routing information asynchrony, so that it fails to predict the inbound direction of an incoming packet if the route if asymmetric. In the last section, we listed five causes of routing information asynchrony, i.e. asymmetric link metrics, ECMP, static routing and local routing policy, fast reroute, and inter-domain route aggregation. We discuss them in greater detail in this section, because we believe these are the challenges that need to be conquered by the SAVI-BF solutions. 3.1. Asymmetric Link Metrics Some routing protocols, like BGP, EIGRP, OSPF and IS-IS, allow asymmetric link metrics, which finally cause routing asymmetry. Bi & Liu Expires August 2, 2012 [Page 9] Internet-Draft SAVI Problem Beyond First Hop January 2012 However, we observe that, using a link-state routing protocol (OSPF, IS-IS), a router has sufficient information to learn the asymmetric link metrics. To utilizing this information, a router should build a reverse forwarding tree (RFT) using the reverse link metrics, instead of using the forward link metrics like RPF doing so. However, for a distance-vecter routing protocol (RIP, EIGRP, BGP), the reverse link metrics are not available to all nodes, so they couldn't build RFT correctly. 3.2. ECMP There could be multiple equally good paths (ECMPs) from the source to the destination. Source may choose one of them randomly or by some means that the destination doesn't know. So the destination has to maintain the multipul equally good paths (if it is able to know them) as valid incoming directions. Although Feasible RPF is designed to solve this issue, in practice hardward capacity is usually insufficient to hold all the ECMP entries. Last but not least, this issue is solved only if the source and the destination see a same set of best paths; otherwise it is useless for the destination to hold the ECMPs that are different from those held by the source. 3.3. Static Routing and Local Routing Policy Static routing is often used to configure a default route, select a route from ECMPs, or implement traffic engineering. Local routing policy is typically implemented with policy routing. It is often used in inter-domain routing as a method to implement local preference and reflect the AS economic relationship. The problem with static routing and local routing policy is that, they are not propogated to other nodes in the network. And in some cases, this information, like the AS economic relationship, should not be disclosed. So it may not be practical to get it in some scenarios. 3.4. Fast Reroute Fast reroute is used to protect against link or router failure. On link or router failure, the router immediately switch the exit of the packets to another locally computed next hop. Fast reroute challeges SAVI-BF in two dimensions. First, the backup route is computed locally without propogated to the network. Second, the time to switch to the backup route is very short, and the other routers couldn't react that fast. So some packets may be dropped since they suddenly arrive from an unexpected direction, which offsets the effect of fast reroute. Bi & Liu Expires August 2, 2012 [Page 10] Internet-Draft SAVI Problem Beyond First Hop January 2012 3.5. Inter-domain Route Aggregation Although inter-domain route aggregation has a lot benefits, it is not worthwhile for a provider to aggregate the prefixes of its customers. Because if the customers are multi-homed, the inbound traffic will be attracted by the other providers. Besides this economic concern, the provider should reserve the orgin AS for the prefix in the BGP advertisement. That is to say, we suggest inter-domain route aggregation not be implemented, especially when it may cause troubles to SAVI-BF. 4. Deployment Incentive In the previous sections, we have discussed the technical problems and challenges of SAVI-BF. However, in practice, technical barrier is not the only barrier that suppresses the deployment of SAVI-BF. Another barrier is the economic incentive, i.e. how can an ISP promote its bussiness or make more money by deploying SAVI-BF. For example, if a SAVI-BF mechanism costs too much but cannot improve an ISP's business, the ISP won't deploy it even if it is technically practical. Hence, depolyment incentive is also an important concern when designing a SAVI-BF mechanism. In this section, we discuss the deployment incentive for ISPs in the intra-domain scenario and inter- domain scenario respectively. 4.1. Intra-Domain In the intra-domain scenario, an ISP may want to deploy SAVI-BF for better security, accountability and manageability. Most of the benefit, or outcome from deploying the intra-domain SAVI-BF is gained by the ISP itself. So an intra-domain SAVI-BF is deployable if it is technically practical, and secuirty, accountability and manageability are important concerns to the ISP. 4.2. Inter-Domain In the context of the inter-domain scenario, SAVI-BF is implemented in the AS border routers (ASBR) to filter spoofing packets before their leaving or entering the AS. In this scenario, accountability and manageability are not the top concern of the ISPs, and the top concern is security, i.e. reducing the inbound spoofing packets. First, we define the "benefit" of an AS as the reduction of its inbound spoofing packets. For instance, assume that the amount of global spoofing packets targeting AS T is t, and a portion of the spoofing packets is filtered because some other ASes have deployed some inter-domain SAVI-BF (e.g. RPF), then the amount of T's Bi & Liu Expires August 2, 2012 [Page 11] Internet-Draft SAVI Problem Beyond First Hop January 2012 received inbound spoofing packets is r. We define the benefit of T as (t-r)/t, i.e. the reduction of T's received inbound spoofing packets. Then we define "incentive" of T as the additional benefit if T also deploys the inter-domain SAVI-BF. More precisely, denoting T's benefit before T deploys the inter-domain SAVI-BF as ben(T, D), where D is the set of ASes who have already deployed the SAVI-BF, and T's benefit after T's deployment as ben(T, D+T), then T's incentive is formulated as inc(T, D) = ben(T, D+T) - ben(T, D). This definition of incentive emphasizes two properties. First, an inter-domain SAVI-BF should protect the deployers, in term of reducing the deployers' received spoofing packets. Second, the SAVI-BF should prevent "free-ride", i.e. the late deployers should gain enough additional benefit; otherwise they just enjoy the "free- ride" and won't deploy by itself. We observe that the ISPs always want to maximize their own profits, not the public welfare. If an ISP already benefits a lot from other ISPs' deployment, and it can only get very trivial additional benefit by its own deployment, then perhaps this ISP won't deploy it. Take RPF for example. All ASes who have already deployed RPF try to filter out all the spoofing packets that they can detect, not only those spoofing packets targeting themselves. RPF, instead of maximizing the deployers' benefit, tries to maximize the public welfare. The drawback of it is that if a portion of ASes have deployed RPF, other ASes can get a "free-ride" and may not want to deploy by themselves because the additional benefit is low. Research [Spoofer] shows that the deployment progress of RPF is slower than the growth of the Internet. The lack of deployment incentive may be the essential reason. However maximizing deployment incentive does not necessarily mean sacrificing the public welfare. Research [DIA] shows that high incentive can motivates more ASes to deploy, and with more deployment the public welfare gets higher. So we claim that maximizing deployment incentive is a key issue in the designing of inter-domian SAVI-BF. 5. Discussion In this section, we discuss the philosophy on designing a SAVI-BF mechanism. Bi & Liu Expires August 2, 2012 [Page 12] Internet-Draft SAVI Problem Beyond First Hop January 2012 5.1. Distributing Routing Information or Routing Decisions In the previous sections, we presented the challenges to SAVI-BF. Although better utilizing the routing information in link-state routing protocols can solve the "asymmetric link metrics" issue, it cannot solve the other four issues. That is because some routing decisions are made locally and not propogated to the network, and other routers cannot predict the routing decisions. Rather than distributing all the routing information (including the local routing policy) and let the other routers to compute and "guess" the routing decisions of each router, another methodology is to directly distribute the routing decisions, i.e. FIB, to the network, so that other routers can straightforward generate the routing graph of the network. We also observe that in some scenarios, like inter-domain routing, the routing decision, which reflects the economic relationship, should not be disclosed. In this case, we should respect the ISP's privacy and put SAVI-BF in the second place. 5.2. Distributed or Centralized Whether a SAVI-BF mechanism should be ditributed or centralized depends on the application environment. A centralized mechanism may be suitable to a small scale intra-domain environment. In the inter- domain scenario, a distributed mechanism is perferred because of there is not a natural center in the inter-domain system. Ingress Filtering is an example of distributed mechanism, where all ASes or routers enforce source address validation in a distributed way without a center to control them. In a small scale intra-domain environment, however, a central server can be used to collecing routing decisions (FIBs) of all the routers, compute the filtering tables and load them to the routers. In this way, the routers don't need to collecting the routing information or compute the reverse paths. All they need is running Simple Network Management Protocol (SNMP) and available Access Control Lists (ACL). 5.3. Routing Protocol Dependent or Independent In the previous section, we show that better utilizing routing protocol information can improve SAVI-BF in link-state routing protocols, but not in distance-vector routing protocols. So the utility of this method is routing protocol dependent. In contrast, the method proposed in the last subsecion (i.e. using a central server to collect FIBs, generate ACLs and download ACLs to routers) is routing protocol independent. The risks of routing protocol Bi & Liu Expires August 2, 2012 [Page 13] Internet-Draft SAVI Problem Beyond First Hop January 2012 dependent method are two fold. First, if the routing information is incomplete, the method fails. Second, if the routing protocol evolves or upgrades, the method may need to upgrade as well. Another question about routing protocol is that whether to update or extend the rouing prototols to help with SAVI-BF. Well, updating routing protocols is out of the scope of SAVI WG. However, designing a new routing protocol may consider SAVI-BF issues. 5.4. Deployment Incentive or Regulation The lesson from the deployment of RPF shows that providing incentive to ISPs to deploy SAVI-BF could be very challenging. "Free-riders" may not deploy. ISPs that don't have DDoS threats may not deploy. And the methods that cost too much won't get deployed. Another methodology is to regulate the industry. Let the government or the industrial association to make SAVI-BF a "must". 6. Acknowledgment The authors would like to thank Fred Baker for his review, comments, and suggestions on anti-spoofing with SPF-based protocols. We also thank Joel M. Halper for his comments on fast reroute. This document was generated using the xml2rfc tool. 7. IANA Considerations This memo asks the IANA for no new parameters. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the authors' perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. 8. Security Considerations 9. Informative References [ARBOR] McPherson, D., Dobbins, R., Hollyman, M., Labovitz, C., and J. Nazario, "Network Infrastructure Security Report", February 2009. Bi & Liu Expires August 2, 2012 [Page 14] Internet-Draft SAVI Problem Beyond First Hop January 2012 [ASPP] Chang, R. and M. Lo, "Inbound traffic engineering for multihomed ASs using AS path prepending", March 2005. [Aggregation] Chen, E. and J. Stewart, "A Framework for Inter-Domain Route Aggregation", RFC 2519, February 1999. [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, BCP 38, May 2000. [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", RFC 3704, BCP 84, March 2004. [BGP-Table] Huston, G., "AS6447 BGP Routing Table Analysis Report", November 2011. [DIA] Liu, B., Bi, J., and Y. Zhu, "A Deployable Approach for Inter-AS Anti-spoofing", October 2011. [ECMP] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000. [Fast-Reroute-Framework] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010. [Fast-Reroute-MPLS] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [Hot-Potato] Teixeira, R., Shaikh, A., Griffin, T., and J. Rexford, "Dynamics of Hot-Potato Routing in IP Networks", June 2004. [Spoofer] Beverly, R., Berger, A., Hyun, Y., and k. claffy, "Understanding the Efficacy of Deployed Internet Source Address Validation Filtering", August 2009. Bi & Liu Expires August 2, 2012 [Page 15] Internet-Draft SAVI Problem Beyond First Hop January 2012 Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@tsinghua.edu.cn Bingyang Liu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China Email: liuby@netarchlab.tsinghua.edu.cn Bi & Liu Expires August 2, 2012 [Page 16]