SAVI J. Bi Internet-Draft B. Liu Intended status: Informational Tsinghua Univ. Expires: November 21, 2012 May 20, 2012 Problem Statement of SAVI Beyond the First Hop draft-bi-savi-problem-03 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. However, since SAVI requires the edge routers or switches to be upgraded, the deployment of SAVI will need a long time. During this transition period, some techniques for source address validation beyond the first hop (SAVI-BF) may be needed to complement SAVI. In the document, we analyze the problems of the current SAVI-BF technique, and discuss the directions we can explore to improve SAVI-BF. 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." This Internet-Draft will expire on November 21, 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 Bi & Liu Expires November 21, 2012 [Page 1] Internet-Draft SAVI Problem Beyond First Hop May 2012 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 November 21, 2012 [Page 2] Internet-Draft SAVI Problem Beyond First Hop May 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problems of Ingress Filtering . . . . . . . . . . . . . . . . . 4 2.1. Not Self-protective . . . . . . . . . . . . . . . . . . . . 4 2.2. False Positives . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Other Reasons . . . . . . . . . . . . . . . . . . . . . . . 5 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Self-protectability is the Most Desirable Property . . . . 5 3.2. Fully Automatic Technique Without False Positives . . . . . 6 3.3. Non-technical Directions . . . . . . . . . . . . . . . . . 6 4. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Bi & Liu Expires November 21, 2012 [Page 3] Internet-Draft SAVI Problem Beyond First Hop May 2012 1. Introduction 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. However, since SAVI requires the edge routers or switches to be upgraded, the deployment of SAVI will need a long time. During this transition period, some anti- spoofing techniques beyond the first hop are needed to complement SAVI. In practice, the only available anti-spoofing technique beyond the first hop is ingress filtering, which was proposed in 2000 as the best current anti-spoofing practice [BCP38]. Today, many commodity routers are capable of ingress filtering, including reverse path forwarding (RPF) and ingress access lists (IALs), which are typically implemented with access control lists (ACLs). Many network administrators have turned on RPF on their routers or actively maintain IALs to filter spoofing traffic, and the fraction of networks where spoofing is possible is significantly limited [MIT-Spoofer]. However, as shown by the recent measurement, the deployment of ingress filtering has not been improved over four years because the ISPs do not have incentive to deploy it, and sophisticated attackers exploit the spoofable networks to launch attacks, so IP spoofing remains a viable attack vector on the current Internet [Efficacy]. In this document, we analyze the problems of ingress filtering to understand why it lacks of deployment incentives for the ISPs. Based on the analysis of the problems, we discuss the directions we can explore to improve the source address validation beyond the first hop (SAVI-BF). 2. Problems of Ingress Filtering In this section, we analyze the reasons why ingress filtering is not applied in a lot of networks. 2.1. Not Self-protective Ingress filtering is only effective when applied near the source end. When applied at the destination end, the incoming direction of a source prefix is hard to determine; even if it can be determined, the allowed source prefix space in this direction is too large to effectively detect spoofing. As a result, deploying ingress filtering (at the source end) is all about "being a good Internet citizen", but provides very littel self-protection to the ISPs Bi & Liu Expires November 21, 2012 [Page 4] Internet-Draft SAVI Problem Beyond First Hop May 2012 [MIT-Spoofer] [NANOG-Incentive]. 2.2. False Positives With the existance of inter-domain routing policies and the popularity of multi-homing, routing asymmetry is very common on the Internet. However, RPF, the automatic technique of ingress filteirng, often filters legitimate packets under routing asymmetry, so called false positives. False postives introduce business risks to the ISPs, as they may lose customers if they drop their customers' traffic [NANOG-Risk]. As a result, the ISPs should carefully examine their networks and find out the interfaces where the risks exist. At these interfaces, the ISPs either turn off RPF, or use IALs to complement RPF or independently [NANOG-Cost], which introduces non- trivial manual configuration and operational cost, especially when the network (topology and routing) is dynamic. 2.3. Other Reasons The lack of self-protection and the risk of false positives are the two main reasons why ingress filtering is not applied by a lot of ISPs, but they are not the only reasons. Although most commodity routers are capable of ingress filtering, some legacy routers are incapable [NANOG-Equipment]. Hence, even at the locations where no risk exists (e.g. stub or single-homed networks), ingress filtering may not be applied. Another reason is called inertia. Since ingress filtering is not enabled on routers by default, some network administrators just won't bother to turn it on [NANOG-PowerOfDefaults]. 3. Discussion Based on the analysis of the problems of ingress filtering, in this section, we discuss the directions we can explore to improve the source address validation beyond the first hop (SAVI-BF). 3.1. Self-protectability is the Most Desirable Property To motivate an ISP to deploy a technique, it is desirable that the technique can generate benefit for the ISP. Applying this theory to source address validation, we get that self-protectability is the most desirable property of a SAVI-BF technique. If a technique can protect an ISP from spoofing based attacks, the ISP is more likely to take the risk and the cost to apply it, just like the incentive they operate firewalls in their network. We are not the first ones who observed this insight. R. Beverly et Bi & Liu Expires November 21, 2012 [Page 5] Internet-Draft SAVI Problem Beyond First Hop May 2012 al. emphasized the protection of deployers in the defination of the anti-spoofing solution space [Efficacy]. Besides there have been many anti-spoofing proposals, which seek to improve the protection of the deployers [SPM] [Passport] [DIA]. Unfortunately, none of them get widely deployed in practice, which indicates that designing a feasible self-protective anti-spoofing method can be very challenging. 3.2. Fully Automatic Technique Without False Positives If a self-protective technique is unavailable, the second best option is to lower the business risk and operation cost. To lower the business risk, the false positive of the anti-spoofing method should be very low or even zero. To lower the operational cost, fully automatic mechanisms are desirable so that manual configuration and diagnosis can be eliminated. One possible direction for the research efforts could be inferring source address validation rules from the routing system. Especially, given the link-state routing protocols (IS-IS and OSPF), each router can compute the routes of all source-destination pairs, so that they can infer the expected incoming directions of each source-destination pair. The method can be fully automatic. But false positives may exist due to ECMP or Fast-Reroute. In other scenarios where the entire network routing information is not available for each router but centralized control is possible (intra-domain scenario), a domain server can collect the RIBs from all the routers in this domain, compute the IAL for each router and deploy the IAL on it. 3.3. Non-technical Directions There are also proposals which formulate source address validation as an economic problem or suggest that laws and governance should be enforced. These directions, however, may be out of the scope of IETF. 4. Acknowledgment The authors would like to thank Fred Baker and Joel M. Halper for their review and comments. This document was generated using the xml2rfc tool. 5. Informative References [ARBOR-2009] Bi & Liu Expires November 21, 2012 [Page 6] Internet-Draft SAVI Problem Beyond First Hop May 2012 McPherson, D., Dobbins, R., Hollyman, M., Labovitz, C., and J. Nazario, "Network Infrastructure Security Report", February 2009. [ARBOR-2010] Dobbins, R. and C. Morales, "Network Infrastructure Security Report", February 2010. [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. [Efficacy] Beverly, R., Berger, A., Hyun, Y., and k. claffy, "Understanding the Efficacy of Deployed Internet Source Address Validation Filtering", August 2009. [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. [Ground-Truth] Labovitz, C., "Botnets, DDoS and Ground-Truth", October 2010. [MIT-Spoofer] Beverly, R., "Spoofer Project", January 2012, . [NANOG-8h] Bi & Liu Expires November 21, 2012 [Page 7] Internet-Draft SAVI Problem Beyond First Hop May 2012 Rhett, J., "BCP38 dismissal", 2008 September, . [NANOG-Cost] Oberman, K., "an effect of ignoring BCP38", 2008 September, . [NANOG-Equipment] Bicknell, L., "BCP38 Deployment", March 2012, . [NANOG-Helpless] Bulk, F., "Are we really this helpless? (Re: isprime DOS in progress)", January 2009, . [NANOG-Incentive] Bicknell, L., "BCP38 Deployment", March 2012, . [NANOG-PowerOfDefaults] Donelan, S., "BCP38 Deployment", March 2012, . [NANOG-Risk] Gilmore, P., "BCP38 Deployment", March 2012, . [Passport] Liu, X., Li, A., Yang, X., and D. Wetherall, "Passport: Secure and Adoptable Source Authentication", 2008. [SPM] Anat, A. and H. Hanoch, "Spoofing Prevention Method", March 2005. Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@tsinghua.edu.cn Bi & Liu Expires November 21, 2012 [Page 8] Internet-Draft SAVI Problem Beyond First Hop May 2012 Bingyang Liu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China Email: liuby@netarchlab.tsinghua.edu.cn Bi & Liu Expires November 21, 2012 [Page 9]