Network Working Group J. Bi Internet-Draft B. Liu Intended status: Informational Tsinghua Univ. Expires: August 1, 2012 January 29, 2012 Problem Statement of SAVI Beyond the First Hop draft-bi-savi-problem-00 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. Despite the drafts that are being actively standardized, the process of deployment on the Internet will take a long time, because the edge of the Internet is too huge. Therefore some source address validation mechanisms implemented beyond the first hop (SAVI-BF) are needed to suppress source address spoofing inside the network. So far, Ingress Filtering [BCP38]/[BCP84] is the best current practice for SAVI-BF. 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 problems of Ingress Filtering under SAVI-BF scenario. Then we discuss how to better utilize the routing information to better enforce SAVI-BF, in the case of link-state and distance-vector routing protocols respectively. Challenges to SAVI-BF, such as equal-cost multi-path routing (ECMP), static-routing and local routing policy, fast reroute and inter-domain route aggregation are discussed. 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 quite challenging. Finally 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 Bi & Liu Expires August 1, 2012 [Page 1] Internet-Draft SAVI Problem Beyond First Hop January 2012 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." This Internet-Draft will expire on August 1, 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 1, 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. Better Utilizing Routing Protocols . . . . . . . . . . . . . . 9 3.1. Link-State Routing Protocols . . . . . . . . . . . . . . . 10 3.2. Distance-Vector Routing Protocols . . . . . . . . . . . . 10 4. Challenges to SAVI-BF . . . . . . . . . . . . . . . . . . . . 10 4.1. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Static Routing and Local Routing Policy . . . . . . . . . 11 4.3. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Inter-domain Route Aggregation . . . . . . . . . . . . . . 11 5. Deployment Incentive . . . . . . . . . . . . . . . . . . . . . 12 5.1. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . . 12 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Distributing Routing Information or Routing Decisions . . 13 6.2. Distributed or Centralized . . . . . . . . . . . . . . . . 14 6.3. Routing Protocol Dependent or Independent . . . . . . . . 14 6.4. Deployment Incentive or Regulation . . . . . . . . . . . . 14 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Bi & Liu Expires August 1, 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 cause of false positive and false negative of RPF is that the router lacks routing information or fails to utilize the routing information to predict the incoming direction an IP packet. Specifically, in the case of running a link-state routing protocol, a router has the complete routing information of the domain (or an area), but RPF only allows it to reversely use the forth forwarding tree to enforce filtering, which is problematic under asymetric routing, rather than to compute a seperate reverse forwarding tree. And in the case of running a distance-vector routing protocol, a router doesn't have enough routing information to compute the reverse forwarding tree. Besides better utilizing routing information, there are also other challenges to SAVI-BF. For instances, equal-cost multi-path (ECMP), static routing and local routing policy, fast reroute and inter- domain route aggregation. These challenges should be overcomed to make a SAVI-BF mechanism extensively practical. Bi & Liu Expires August 1, 2012 [Page 4] Internet-Draft SAVI Problem Beyond First Hop January 2012 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. In the inter-domain scenario, however, an ISP could not filter much inbound spoofing traffic unless 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. This document is organized as follows. In Section 2, the problems of Ingress Filtering are stated. The discussion about utilizing routing information for link-state and distance-vector routing protocols is presented in Section 3. The challenges to SAVI-BF are discussed in Section 4. Incentives for ISPs to deploy SAVI-BF is discussed in Section 5. Discussion on philosophy of designing a SAVI-BF mechanism is provided in Section 6. 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 present several scenarios that cause 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 Bi & Liu Expires August 1, 2012 [Page 5] Internet-Draft SAVI Problem Beyond First Hop January 2012 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 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. Bi & Liu Expires August 1, 2012 [Page 6] Internet-Draft SAVI Problem Beyond First Hop January 2012 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 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 Bi & Liu Expires August 1, 2012 [Page 7] Internet-Draft SAVI Problem Beyond First Hop January 2012 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 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 1, 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. Better Utilizing Routing Protocols In the last section, we examined the problems of each mode of Ingress Filtering, and showed that the problems are caused by asymmetric routing. We also presented the five issues that result in asymmetric routing, i.e. asymmetric link metrics, ECMP, static routing and local routing policy, fast reroute, and inter-domain route aggregation. Although solving all these five issues is quite challenging and out of scope of this document, we observe that the current best practice can be improved by better utilizing the original routing information propogated by the routing protocols. Ingress Filtering only utilizes FIB or RIB for reverse path checking. However, FIB and RIB, which are generated from the routing information that is propogated via routing protocols, lose a lot of the original information. For example, OSPF propogates the cost of Bi & Liu Expires August 1, 2012 [Page 9] Internet-Draft SAVI Problem Beyond First Hop January 2012 each link on the network, but the FIB exludes that information and only reserves the final routing decisions. In this section, we analyse how the original routing protocol information can help with generating reverse path. And we present the analysis for link-state routing protocols and distance-vector routing protocols seperately. 3.1. Link-State Routing Protocols For a link-state routing protocol (OSPF, IS-IS), every link-state advertisement is propogated over the entire domain (or area). So every router has the complete routing information of the domain (or area) generated by the routing protocol. This indicates that a router may have sufficient information to compute the paths from other routers to itself, and generate a reverse forwarding tree (RFT). To generate the RFT, the route has to compute the shortest paths from every other router to itself using the link-state information. So this RFT is compatible with asymmetric link metrics. Note that the RFT is essentially different from just simply reversing the forth forwarding tree like RPF does, which is naturally incompatible with asymmetric link metrics. Although compatible with asymmetric link metrics, fully utilizing the link-state information doesn't address the other four issues, i.e. ECMP, static routing and local routing policy, fast reroute and inter-domain route aggregation. That is because the information related with those issues are not propogated via routing protocols to other routers on the network. Actually these four issues couldn't be addressed under distance-vector routing protocols either. So we leave them in the Challenge section for discussion. 3.2. Distance-Vector Routing Protocols For a distance-vecter routing protocol(RIP, EIGRP, BGP), the routing information that a router receives is incomplete. So a router is not able to learn the asymmetric link metrics on the network so as to generate the RFT. In fact, the routing information provided by distance-vector routing protocols is not sufficient to solve the other four issues either. 4. Challenges to SAVI-BF As discussed in the last section, the "asymmetric link metrics" can be solved in link-state routing protocols, but cannot be solved in distance-vector routing protocols. There are also four issues letf: ECMP, static routing and local routing policy, fast reroute, and inter-domain route aggregation. In this section, we illustrate more about these challenges. Bi & Liu Expires August 1, 2012 [Page 10] Internet-Draft SAVI Problem Beyond First Hop January 2012 4.1. 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. 4.2. 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. 4.3. 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. 4.4. 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. Bi & Liu Expires August 1, 2012 [Page 11] Internet-Draft SAVI Problem Beyond First Hop January 2012 5. 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, because of the different benefit the ISPs gain from SAVI-BF. 5.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. 5.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 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). Bi & Liu Expires August 1, 2012 [Page 12] Internet-Draft SAVI Problem Beyond First Hop January 2012 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. 6. Discussion In this section, we discuss the philosophy on designing a SAVI-BF mechanism. 6.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 Bi & Liu Expires August 1, 2012 [Page 13] Internet-Draft SAVI Problem Beyond First Hop January 2012 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. 6.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). 6.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 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. 6.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" Bi & Liu Expires August 1, 2012 [Page 14] Internet-Draft SAVI Problem Beyond First Hop January 2012 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". 7. 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. 8. 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. 9. Security Considerations 10. Informative References [ARBOR] McPherson, D., Dobbins, R., Hollyman, M., Labovitz, C., and J. Nazario, "Network Infrastructure Security Report", February 2009. [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 Bi & Liu Expires August 1, 2012 [Page 15] Internet-Draft SAVI Problem Beyond First Hop January 2012 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. Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@tsinghua.edu.cn Bi & Liu Expires August 1, 2012 [Page 16] Internet-Draft SAVI Problem Beyond First Hop January 2012 Bingyang Liu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China Email: liuby@netarchlab.tsinghua.edu.cn Bi & Liu Expires August 1, 2012 [Page 17]