One document matched: draft-bi-savi-problem-01.txt
Differences from draft-bi-savi-problem-00.txt
SAVI J. Bi
Internet-Draft B. Liu
Intended status: Informational Tsinghua Univ.
Expires: August 2, 2012 January 30, 2012
Problem Statement of SAVI Beyond the First Hop
draft-bi-savi-problem-01
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. For source address validation
beyond the first hop (SAVI-BF), Ingress Filtering [BCP38]/[BCP84] is
the best current practice. 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 possible scenarios in which Ingress
Filtering may have problems (false positive or false negative), and
lists five causes of the problems. These fives causes, we believe,
are the challeges that need be conquered by SAVI-BF solutions
(including possible improved version of Ingress Filtering). 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 more
challenging. Although not intend to provide any SAVI-BF solution in
this document, 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
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."
Bi & Liu Expires August 2, 2012 [Page 1]
Internet-Draft SAVI Problem Beyond First Hop January 2012
This Internet-Draft will expire on August 2, 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 2, 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. Challenges to SAVI-BF . . . . . . . . . . . . . . . . . . . . 9
3.1. Asymmetric Link Metrics . . . . . . . . . . . . . . . . . 9
3.2. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Static Routing and Local Routing Policy . . . . . . . . . 10
3.4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Inter-domain Route Aggregation . . . . . . . . . . . . . . 11
4. Deployment Incentive . . . . . . . . . . . . . . . . . . . . . 11
4.1. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . . 11
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Distributing Routing Information or Routing Decisions . . 13
5.2. Distributed or Centralized . . . . . . . . . . . . . . . . 13
5.3. Routing Protocol Dependent or Independent . . . . . . . . 13
5.4. Deployment Incentive or Regulation . . . . . . . . . . . . 14
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Bi & Liu Expires August 2, 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 reason of the problems of Ingress Filtering, is the lack of
routing information, because the behavior of a SAVI-BF solution
should adhere to the routing system. If the routing information on
routers is asynchronous, a router may fail to predict the inbound
direction of an incoming packet from other routers when the route is
asymmetric. We list five causes that result in the routing
information asynchrony, i.e. asymmetric link metrics, equal-cost
multi-path (ECMP), static routing and local routing policy, fast
reroute and inter-domain route aggregation. These causes, we
believe, are the challeges that need be conquered by SAVI-BF
solutions (including possible improved version of Ingress Filtering)
to make the solutions more extensively practical.
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.
Bi & Liu Expires August 2, 2012 [Page 4]
Internet-Draft SAVI Problem Beyond First Hop January 2012
In the inter-domain scenario, however, an ISP could not filter much
inbound spoofing traffic unless the 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, in the
sense that an ISP is a benefit unit in the Internet.
This document is organized as follows. In Section 2, the problems of
Ingress Filtering are stated. The challenges to SAVI-BF are
discussed in Section 3. Incentives for ISPs to deploy SAVI-BF is
discussed in Section 4. Discussion on philosophy of designing a
SAVI-BF mechanism is provided in Section 5.
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 list five causes of 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
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
Bi & Liu Expires August 2, 2012 [Page 5]
Internet-Draft SAVI Problem Beyond First Hop January 2012
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.
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
Bi & Liu Expires August 2, 2012 [Page 6]
Internet-Draft SAVI Problem Beyond First Hop January 2012
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
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
Bi & Liu Expires August 2, 2012 [Page 7]
Internet-Draft SAVI Problem Beyond First Hop January 2012
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 2, 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. Challenges to SAVI-BF
The reason of the problems of Ingress Filtering is routing
information asynchrony, so that it fails to predict the inbound
direction of an incoming packet if the route if asymmetric. In the
last section, we listed five causes of routing information
asynchrony, i.e. asymmetric link metrics, ECMP, static routing and
local routing policy, fast reroute, and inter-domain route
aggregation. We discuss them in greater detail in this section,
because we believe these are the challenges that need to be conquered
by the SAVI-BF solutions.
3.1. Asymmetric Link Metrics
Some routing protocols, like BGP, EIGRP, OSPF and IS-IS, allow
asymmetric link metrics, which finally cause routing asymmetry.
Bi & Liu Expires August 2, 2012 [Page 9]
Internet-Draft SAVI Problem Beyond First Hop January 2012
However, we observe that, using a link-state routing protocol (OSPF,
IS-IS), a router has sufficient information to learn the asymmetric
link metrics. To utilizing this information, a router should build a
reverse forwarding tree (RFT) using the reverse link metrics, instead
of using the forward link metrics like RPF doing so. However, for a
distance-vecter routing protocol (RIP, EIGRP, BGP), the reverse link
metrics are not available to all nodes, so they couldn't build RFT
correctly.
3.2. 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.
3.3. 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.
3.4. 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.
Bi & Liu Expires August 2, 2012 [Page 10]
Internet-Draft SAVI Problem Beyond First Hop January 2012
3.5. 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.
4. 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.
4.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.
4.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
Bi & Liu Expires August 2, 2012 [Page 11]
Internet-Draft SAVI Problem Beyond First Hop January 2012
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).
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.
5. Discussion
In this section, we discuss the philosophy on designing a SAVI-BF
mechanism.
Bi & Liu Expires August 2, 2012 [Page 12]
Internet-Draft SAVI Problem Beyond First Hop January 2012
5.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
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.
5.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).
5.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
Bi & Liu Expires August 2, 2012 [Page 13]
Internet-Draft SAVI Problem Beyond First Hop January 2012
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.
5.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"
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".
6. 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.
7. 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.
8. Security Considerations
9. Informative References
[ARBOR] McPherson, D., Dobbins, R., Hollyman, M., Labovitz, C.,
and J. Nazario, "Network Infrastructure Security Report",
February 2009.
Bi & Liu Expires August 2, 2012 [Page 14]
Internet-Draft SAVI Problem Beyond First Hop January 2012
[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
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.
Bi & Liu Expires August 2, 2012 [Page 15]
Internet-Draft SAVI Problem Beyond First Hop January 2012
Authors' Addresses
Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China
Email: junbi@tsinghua.edu.cn
Bingyang Liu
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
Email: liuby@netarchlab.tsinghua.edu.cn
Bi & Liu Expires August 2, 2012 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 05:26:18 |