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]