Internet DRAFT - draft-bi-savi-problem
draft-bi-savi-problem
SAVI J. Bi
Internet-Draft B. Liu
Intended status: Informational Tsinghua Univ.
Expires: November 10, 2017 May 9, 2017
Problem Statement of SAVI Beyond the First Hop
draft-bi-savi-problem-13
Abstract
IETF Source Address Validation Improvements (SAVI) working group is
chartered for source address validation within the first hop from 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 source address
validation techniques beyond the first hop (SAVI-BF) may be needed to
complement SAVI and protect the networks from spoofing based attacks.
In this document, we first propose three desired features of the
SAVI-BF techniques. Then we analyze the problems of the current
SAVI-BF technique, ingress filtering. Finally, we discuss the
directions that 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 10, 2017.
Copyright Notice
Copyright (c) 2017 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
Bi & Liu Expires November 10, 2017 [Page 1]
Internet-Draft SAVI Problem Beyond First Hop May 2017
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Desired Features of SAVI-BF Techniques . . . . . . . . . . . 3
2.1. High Deployment Incentives . . . . . . . . . . . . . . . 3
2.2. Low Operational Risks . . . . . . . . . . . . . . . . . . 3
2.3. Low Cost . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problems of Ingress Filtering . . . . . . . . . . . . . . . . 4
3.1. IAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Strict/feasible RPF . . . . . . . . . . . . . . . . . . . 5
3.3. Loose RPF* . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Other Reasons . . . . . . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Path based Techniques . . . . . . . . . . . . . . . . . . 7
4.2. End-to-end based Techniques . . . . . . . . . . . . . . . 7
4.3. Non-technical Proposals . . . . . . . . . . . . . . . . . 8
5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
IETF Source Address Validation Improvements (SAVI) working group is
chartered for source address validation within the first hop from the
end hosts, so as to prevent 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
Bi & Liu Expires November 10, 2017 [Page 2]
Internet-Draft SAVI Problem Beyond First Hop May 2017
source address validation techniques beyond the first hop (SAVI-BF)
may be needed to complement SAVI, so as to protect the networks from
spoofing based attacks, which are prevalent DDoS attacks on the
current Internet [Ground-Truth] [ARBOR-2010] [NANOG-Helpless]
[DrDoS-300Gbps].
In this document, we first propose three desired features of SAVI-BF
techniques. The first desired feature is high deployment incentives,
i.e., by deploying a technique, an ISP should significantly increase
its ability to protect its network from spoofing based attacks. The
second one is low operational risks. If a technique may improperly
drop legitimate packets (so called false positives), it introduces
new risks to the network operation and management. It is desired
that the false positives (FP) is as low as possible. The third one
low cost. It is desired that the technique requires minimum
deployment investment and operational cost.
We evaluate ingress filtering [BCP38] [BCP84], the best current
practice in for SAVI-BF, against these three features. Recent
measurement shows that, the deployment of ingress filtering has not
been improved over four years because the ISPs do not have incentives
to deploy it [Efficacy], and sophisticated attackers exploit the
spoofable networks to launch attacks. We discuss the reasons why
ingress filtering is still insufficiently applied by the ISPs despite
that it has long been available in modern routers.
Finally, we discuss the directions that we can explore to improve
SAVI-BF. We briefly survey two categories of SAVI-BF proposals, the
path based techniques and the end-to-end based techniques. We
discuss their requirements, advantages and disadvantages.
2. Desired Features of SAVI-BF Techniques
2.1. High Deployment Incentives
To motivate an ISP to deploy a technique, it is desirable that the
technique can generate additional benefit for the ISP. In terms of a
SAVI-BF technique, it should provide the ISP with additional
protection from spoofing based attacks. Specifically, it should
significantly decrease the volume of the spoofing based attacks
targeting the ISP, or the number of networks where these attacks can
be successfully launched, or the number of source addresses or
destination addresses that can be used in these attacks.
2.2. Low Operational Risks
If a technique may improperly drop legitimate packets, so called
false positives (FP), it introduces new operational risks.
Bi & Liu Expires November 10, 2017 [Page 3]
Internet-Draft SAVI Problem Beyond First Hop May 2017
Apparently, it is desired that the FP is as low as possible. The
higher the FP, the more limited its application scope. For example,
if the attack is not very severe, the network administrator would not
apply a technique with high FP, since its operation risks may even
surpass the loss caused by the attack.
2.3. Low Cost
It is desired that the technique requires minimum investment on the
device and system upgrading. It should also adapt to network
dynamics rather than require manual intervention, which is costly,
slow, and often the source of errors (misconfiguration).
3. Problems of Ingress Filtering
Ingress filtering is the best current practice for SAVI-BF. Ingress
filtering was proposed in 2000 [BCP38] , and updated in 2004 [BCP84].
Ingress access lists (IALs) and unicast reverse path forwarding
(uRPF) are two general ways to implement ingress filtering. An IAL
is a filter that checks the source address of every packet received
on a network interface against a list of acceptable prefixes,
dropping any packet that does not match the filter. IALs are
typically maintained manually. Upon network dynamics (topology
change or routing change), the IALs should be updated accordingly to
avoid dropping legitimate packets. uRPF is an automated tool which
can adapt with the network dynamics. On the receipt of a packet,
uRPF checks its source address against the forwarding table or
routing table for validation. uRPF has four variants, strict RPF,
feasible RPF, loose RPF and loose RPF ignoring default routes.
Readers are referred to [BCP84] for the details of these variants.
Today, many modern routers are capable of ingress filtering. Many
network administrators have turned on uRPF on their routers or been
actively maintaining IALs to filter spoofing traffic. 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. Sophisticated attackers can still exploit the networks where
spoofing is possible to launch spoofing based attacks, and IP
spoofing remains a viable attack vector on the current Internet
[Efficacy].
In this section, we evaluate ingress filtering against the desired
features, and analyze the reasons why ingress filtering is not
sufficiently deployed, and why its deployment has not been improved
over years. We classify the five variants of ingress filtering (IAL
and four variants of uRPF) into three categories according to their
technical similarities, i.e., IALs, strict/feasible RPF, and loose
Bi & Liu Expires November 10, 2017 [Page 4]
Internet-Draft SAVI Problem Beyond First Hop May 2017
RPF* (including loose RPF and loose RPF ignoring default routes).
The evaluation results are summarized in Table 1, which will be
explained in detail in the following subsections.
+---------------------+-----------+------+------+
| Techniques | Incentive | Risk | Cost |
+---------------------+-----------+------+------+
| IAL | low | low | low |
| - | - | - | - |
| Strict/feasible RPF | high | high | low |
| - | - | - | - |
| Loose RPF* | low | low | low |
+---------------------+-----------+------+------+
Table 1: Evaluation of Ingress Filtering
3.1. IAL
IAL can be applied at network border routers and enforced on outbound
packets. All the outbound packets whose source addresses do not
belong to the local network are identifed as spoofed. Since it only
filters outbound packets, and cannot protect the local network from
receiving spoofing packets, it provides little deployment incentives.
When IAL is enforced on inbound packets, there are two typical
scenarios. In the first scenario, it is applied on the routers'
ingress interface connecting a stub network. In this case, the
source address space of the stub network can be configured on this
interface, and all inbound packets whose source addresses fall out of
this address space are identified as spoofed. Since the address
space size of directly connected stub networks is very small compared
to the entire routable address space, the effectiveness is low. In
the second scenario, the directly connected network is not stub, and
thus the valid address space of inbound packets is hard to determine.
In this case, IAL can only safely drop the inbound packets whose
source addresses belong to the local network. It is very ineffective
since the address space size of the local network very small compared
to the entire routable address space. To summize, IAL provides low
deployment incentives in all cases. If well maintained, false
positives can also be avoided. IAL can be implemented using the
existing functions on routers (access control lists, ACLs), and thus
do not require additional investment. Overall, the deployment cost
is low except in the "stub-network" scenario, where the address space
of all stubs need to be carefully maintained, which may require heavy
manual configuration if there are many directly connected stub
networks.
3.2. Strict/feasible RPF
Bi & Liu Expires November 10, 2017 [Page 5]
Internet-Draft SAVI Problem Beyond First Hop May 2017
Strict and feasible RPF can adapt themselves to the routing dynamics
and determine the incoming directions of source prefixes
automatically. They are more effective than IAL in detecting and
filtering spoofing traffic, and thus provide higher deployment
incentives to the ISPs. However, they often drop legitimate packets
under routing asymmetry, which is very prevalent with the existence
of local routing policies, multi-homing and traffic engineering.
This makes strict and feasible very risky [NANOG-Risk], and hence the
operation needs to be very careful. Feasible RPF has lower FP than
strict RPF, since it can apply multiple interfaces as acceptable
incoming directions for a source prefix. But feasible RPF cannot
avoid all FP in practice, since currently there is no practical way
to generate and configure all possible incoming directions in the
routers. For example, in a link-state routing environment (IS-IS or
OSPF), equal-cost multi-path (ECMP) [ECMP] is often used to generate
the multiple acceptable incoming directions. However, in practice,
there can be many (tens of) ECMPs for a prefix, but the
implementation of a router can only store several (e.g., 4 or 8) of
them. Thus, the ECMPs for the prefix installed in the forwarding
table may be different in different routers, which eventually causes
the FP of feasible RPF. And in BGP, the directions where BGP
announcements for a source address prefix have been received can be
considered as acceptable incoming directions [IDPF]. However, an ISP
may choose not to announce a prefix via a path but still send traffic
through it due to its local routing policy. In this case, feasible
RPF also causes FP. The basic function of strict and feasible RPF is
supported in most modern routers. So deploying them doesn't require
investment on upgrading devices.
3.3. Loose RPF*
Instead of validating the incoming direction of a source address,
loose RPF* only checks the existence of the source address in the
forwarding table. Loose RPF* is only useful for filtering Martian
addresses and unroutable addresses. However, sophisticated attackers
can evade loose RPF* checking by simply using routable source
addresses. Thus the incentive to deploy loose RPF is low. On the
other hand, its operational risk is also low. Loose RPF* is also
available in most modern routers, making it cheap to deploy.
3.4. Other Reasons
There are other reasons why the deployment of ingress filtering
hasn't been improved in four years. First, although most modern
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
Bi & Liu Expires November 10, 2017 [Page 6]
Internet-Draft SAVI Problem Beyond First Hop May 2017
filtering is not enabled on routers by default, some network
administrators just won't bother to turn it on
[NANOG-PowerOfDefaults].
4. Discussion
In this section, we discuss the directions that we can explore to
improve SAVI-BF. We briefly survey two categories of SAVI-BF
proposals, path based techniques and end-to-end based techniques. We
discuss their requirements, advantages and disadvantages. We only
focus on the techniques that are implemented on the routers. The
techniques implemented on end hosts, such as [IPSec], [HCF] and
[IP-Puzzles], are not covered here.
4.1. Path based Techniques
The path based techniques essentially require that a router R knows
the forwarding paths that each source prefix S uses toward its
destinations, and subsequently knows the incoming directions/
interfaces of S. Sometimes, this information is available to R. For
example, in a pure link-state routing protocol environment (e.g., IS-
IS, OSPF), all nodes have the same view of the network. Thus, R can
compute the paths from S to all destinations, and then infer the
incoming directions of S. One exception is that, when there are
multiple equally best paths, R may not determine which one S will
use. On the other hand, if a distance-vector (e.g., RIP) or a path-
vector (BGP) routing protocol is used, it is even harder for R to
determine the paths of S, since the sufficient routing information is
missed. [SAVE] and [IDPF] are tow proposals which validate source
addresses by inferring their forwarding paths.
4.2. End-to-end based Techniques
There are, however, other proposals that don't rely on path
information. We call them end-to-end based techniques. For example,
[SPM] associates each source prefix (indeed, source AS number) with a
key. S, an SPM-enabled AS, will tag the key into outbound packets
toward R at its border routers. And R verifies the keys of the
inbound packets whose source addresses belong to S at its border
routers. The routers will drop a packet if the key is incorrect.
Thus, R manages to validate the source addresses of S without knowing
its forwarding paths. The end-to-end based the techniques typically
need the cooperation between the source and the verification nodes,
and require particular tags be carried in the data packets. Further
more, even the end-to-end based techniques require to distinguish
inbound traffic and outbound traffic, which is not completely path-
independent.
Bi & Liu Expires November 10, 2017 [Page 7]
Internet-Draft SAVI Problem Beyond First Hop May 2017
4.3. Non-technical Proposals
There are also proposals which formulate source address validation as
an economic problem [FaaS], or suggest that laws and governance
should be enforced. These directions, however, may be out of the
scope of IETF.
5. Acknowledgment
The authors would like to thank Fred Baker and Joel M. Halpern for
their comments.
This document was generated using the xml2rfc tool.
6. Informative References
[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.
[DrDoS-300Gbps]
Prince, M., "The DDoS That Almost Broke the Internet",
March 2013.
[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.
[FaaS] Liu, B., Bi, J., and X. Yang, "FaaS: Filtering IP Spoofing
Traffic as a Service", 2012.
[Ground-Truth]
Labovitz, C., "Botnets, DDoS and Ground-Truth", October
2010.
[HCF] Jin, C., Wang, H., and K. Shin, "Hop-count filtering: an
effective defense against spoofed DDoS traffic", 2003.
Bi & Liu Expires November 10, 2017 [Page 8]
Internet-Draft SAVI Problem Beyond First Hop May 2017
[IDPF] Duan, Z., Yuan, X., and J. Ch, "Controlling IP Spoofing
Through Inter-Domain Packet Filters", 2008.
[IP-Puzzles]
Feng, W., Feng, W., and A. Luu, "The Design and
Implementation of Network Puzzles", 2005.
[IPSec] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[MIT-Spoofer]
Beverly, R., "Spoofer Project", January 2012,
<http://spoofer.csail.mit.edu/>.
[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-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>.
[SAVE] Li, J., Mirkovic, J., Wang, M., Reiher, P., and L. Zhang,
"SAVE: Source Address Validity Enforcement Protocol",
2002.
[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 10, 2017 [Page 9]
Internet-Draft SAVI Problem Beyond First Hop May 2017
Bingyang Liu
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China
Email: bingyangliu.cn@gmail.com
Bi & Liu Expires November 10, 2017 [Page 10]
