Problem Statement of SAVI Beyond the First Hop
draft-bi-savi-problem-03

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,
              <http://spoofer.csail.mit.edu/>.

   [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, <http://
              www.nanog.org/mailinglist/mailarchives/old_archive/
              2008-09/msg00184.html>.

   [NANOG-Cost]
              Oberman, K., "an effect of ignoring BCP38",
              2008 September, <http://www.nanog.org/mailinglist/
              mailarchives/old_archive/2008-09/msg00375.html>.

   [NANOG-Equipment]
              Bicknell, L., "BCP38 Deployment", March 2012, <http://
              mailman.nanog.org/pipermail/nanog/2012-March/047139.html>.

   [NANOG-Helpless]
              Bulk, F., "Are we really this helpless? (Re: isprime DOS
              in progress)", January 2009, <http://mailman.nanog.org/
              pipermail/nanog/2009-January/006996.html>.

   [NANOG-Incentive]
              Bicknell, L., "BCP38 Deployment", March 2012, <http://
              mailman.nanog.org/pipermail/nanog/2012-March/047134.html>.

   [NANOG-PowerOfDefaults]
              Donelan, S., "BCP38 Deployment", March 2012, <http://
              mailman.nanog.org/pipermail/nanog/2012-March/047147.html>.

   [NANOG-Risk]
              Gilmore, P., "BCP38 Deployment", March 2012, <http://
              mailman.nanog.org/pipermail/nanog/2012-March/047087.html>.

   [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]