idnits 2.17.1
draft-bi-savi-problem-12.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to contain a disclaimer for pre-RFC5378 work, but was
first submitted on or after 10 November 2008. The disclaimer is usually
necessary only for documents that revise or obsolete older RFCs, and that
take significant amounts of text from those RFCs. If you can contact all
authors of the source material and they are willing to grant the BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (November 13, 2016) is 2714 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SAVI J. Bi
3 Internet-Draft B. Liu
4 Intended status: Informational Tsinghua Univ.
5 Expires: May 17, 2017 November 13, 2016
7 Problem Statement of SAVI Beyond the First Hop
8 draft-bi-savi-problem-12
10 Abstract
12 IETF Source Address Validation Improvements (SAVI) working group is
13 chartered for source address validation within the first hop from end
14 hosts, i.e., preventing a node from spoofing the IP source address of
15 another node in the same IP link. However, since SAVI requires the
16 edge routers or switches to be upgraded, the deployment of SAVI will
17 need a long time. During this transition period, some source address
18 validation techniques beyond the first hop (SAVI-BF) may be needed to
19 complement SAVI and protect the networks from spoofing based attacks.
20 In this document, we first propose three desired features of the
21 SAVI-BF techniques. Then we analyze the problems of the current
22 SAVI-BF technique, ingress filtering. Finally, we discuss the
23 directions that we can explore to improve SAVI-BF.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on May 17, 2017.
42 Copyright Notice
44 Copyright (c) 2016 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 This document may contain material from IETF Documents or IETF
58 Contributions published or made publicly available before November
59 10, 2008. The person(s) controlling the copyright in some of this
60 material may not have granted the IETF Trust the right to allow
61 modifications of such material outside the IETF Standards Process.
62 Without obtaining an adequate license from the person(s) controlling
63 the copyright in such materials, this document may not be modified
64 outside the IETF Standards Process, and derivative works of it may
65 not be created outside the IETF Standards Process, except to format
66 it for publication as an RFC or to translate it into languages other
67 than English.
69 Table of Contents
71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
72 2. Desired Features of SAVI-BF Techniques . . . . . . . . . . . 3
73 2.1. High Deployment Incentives . . . . . . . . . . . . . . . 3
74 2.2. Low Operational Risks . . . . . . . . . . . . . . . . . . 3
75 2.3. Low Cost . . . . . . . . . . . . . . . . . . . . . . . . 4
76 3. Problems of Ingress Filtering . . . . . . . . . . . . . . . . 4
77 3.1. IAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
78 3.2. Strict/feasible RPF . . . . . . . . . . . . . . . . . . . 5
79 3.3. Loose RPF* . . . . . . . . . . . . . . . . . . . . . . . 6
80 3.4. Other Reasons . . . . . . . . . . . . . . . . . . . . . . 6
81 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
82 4.1. Path based Techniques . . . . . . . . . . . . . . . . . . 7
83 4.2. End-to-end based Techniques . . . . . . . . . . . . . . . 7
84 4.3. Non-technical Proposals . . . . . . . . . . . . . . . . . 8
85 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8
86 6. Informative References . . . . . . . . . . . . . . . . . . . 8
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
89 1. Introduction
91 IETF Source Address Validation Improvements (SAVI) working group is
92 chartered for source address validation within the first hop from the
93 end hosts, so as to prevent a node from spoofing the IP source
94 address of another node in the same IP link. However, since SAVI
95 requires the edge routers or switches to be upgraded, the deployment
96 of SAVI will need a long time. During this transition period, some
97 source address validation techniques beyond the first hop (SAVI-BF)
98 may be needed to complement SAVI, so as to protect the networks from
99 spoofing based attacks, which are prevalent DDoS attacks on the
100 current Internet [Ground-Truth] [ARBOR-2010] [NANOG-Helpless]
101 [DrDoS-300Gbps].
103 In this document, we first propose three desired features of SAVI-BF
104 techniques. The first desired feature is high deployment incentives,
105 i.e., by deploying a technique, an ISP should significantly increase
106 its ability to protect its network from spoofing based attacks. The
107 second one is low operational risks. If a technique may improperly
108 drop legitimate packets (so called false positives), it introduces
109 new risks to the network operation and management. It is desired
110 that the false positives (FP) is as low as possible. The third one
111 low cost. It is desired that the technique requires minimum
112 deployment investment and operational cost.
114 We evaluate ingress filtering [BCP38] [BCP84], the best current
115 practice in for SAVI-BF, against these three features. Recent
116 measurement shows that, the deployment of ingress filtering has not
117 been improved over four years because the ISPs do not have incentives
118 to deploy it [Efficacy], and sophisticated attackers exploit the
119 spoofable networks to launch attacks. We discuss the reasons why
120 ingress filtering is still insufficiently applied by the ISPs despite
121 that it has long been available in modern routers.
123 Finally, we discuss the directions that we can explore to improve
124 SAVI-BF. We briefly survey two categories of SAVI-BF proposals, the
125 path based techniques and the end-to-end based techniques. We
126 discuss their requirements, advantages and disadvantages.
128 2. Desired Features of SAVI-BF Techniques
130 2.1. High Deployment Incentives
132 To motivate an ISP to deploy a technique, it is desirable that the
133 technique can generate additional benefit for the ISP. In terms of a
134 SAVI-BF technique, it should provide the ISP with additional
135 protection from spoofing based attacks. Specifically, it should
136 significantly decrease the volume of the spoofing based attacks
137 targeting the ISP, or the number of networks where these attacks can
138 be successfully launched, or the number of source addresses or
139 destination addresses that can be used in these attacks.
141 2.2. Low Operational Risks
143 If a technique may improperly drop legitimate packets, so called
144 false positives (FP), it introduces new operational risks.
146 Apparently, it is desired that the FP is as low as possible. The
147 higher the FP, the more limited its application scope. For example,
148 if the attack is not very severe, the network administrator would not
149 apply a technique with high FP, since its operation risks may even
150 surpass the loss caused by the attack.
152 2.3. Low Cost
154 It is desired that the technique requires minimum investment on the
155 device and system upgrading. It should also adapt to network
156 dynamics rather than require manual intervention, which is costly,
157 slow, and often the source of errors (misconfiguration).
159 3. Problems of Ingress Filtering
161 Ingress filtering is the best current practice for SAVI-BF. Ingress
162 filtering was proposed in 2000 [BCP38] , and updated in 2004 [BCP84].
163 Ingress access lists (IALs) and unicast reverse path forwarding
164 (uRPF) are two general ways to implement ingress filtering. An IAL
165 is a filter that checks the source address of every packet received
166 on a network interface against a list of acceptable prefixes,
167 dropping any packet that does not match the filter. IALs are
168 typically maintained manually. Upon network dynamics (topology
169 change or routing change), the IALs should be updated accordingly to
170 avoid dropping legitimate packets. uRPF is an automated tool which
171 can adapt with the network dynamics. On the receipt of a packet,
172 uRPF checks its source address against the forwarding table or
173 routing table for validation. uRPF has four variants, strict RPF,
174 feasible RPF, loose RPF and loose RPF ignoring default routes.
175 Readers are referred to [BCP84] for the details of these variants.
177 Today, many modern routers are capable of ingress filtering. Many
178 network administrators have turned on uRPF on their routers or been
179 actively maintaining IALs to filter spoofing traffic. The fraction
180 of networks where spoofing is possible is significantly limited
181 [MIT-Spoofer]. However, as shown by the recent measurement, the
182 deployment of ingress filtering has not been improved over four
183 years. Sophisticated attackers can still exploit the networks where
184 spoofing is possible to launch spoofing based attacks, and IP
185 spoofing remains a viable attack vector on the current Internet
186 [Efficacy].
188 In this section, we evaluate ingress filtering against the desired
189 features, and analyze the reasons why ingress filtering is not
190 sufficiently deployed, and why its deployment has not been improved
191 over years. We classify the five variants of ingress filtering (IAL
192 and four variants of uRPF) into three categories according to their
193 technical similarities, i.e., IALs, strict/feasible RPF, and loose
194 RPF* (including loose RPF and loose RPF ignoring default routes).
195 The evaluation results are summarized in Table 1, which will be
196 explained in detail in the following subsections.
198 +---------------------+-----------+------+------+
199 | Techniques | Incentive | Risk | Cost |
200 +---------------------+-----------+------+------+
201 | IAL | low | low | low |
202 | - | - | - | - |
203 | Strict/feasible RPF | high | high | low |
204 | - | - | - | - |
205 | Loose RPF* | low | low | low |
206 +---------------------+-----------+------+------+
208 Table 1: Evaluation of Ingress Filtering
210 3.1. IAL
212 IAL can be applied at network border routers and enforced on outbound
213 packets. All the outbound packets whose source addresses do not
214 belong to the local network are identifed as spoofed. Since it only
215 filters outbound packets, and cannot protect the local network from
216 receiving spoofing packets, it provides little deployment incentives.
217 When IAL is enforced on inbound packets, there are two typical
218 scenarios. In the first scenario, it is applied on the routers'
219 ingress interface connecting a stub network. In this case, the
220 source address space of the stub network can be configured on this
221 interface, and all inbound packets whose source addresses fall out of
222 this address space are identified as spoofed. Since the address
223 space size of directly connected stub networks is very small compared
224 to the entire routable address space, the effectiveness is low. In
225 the second scenario, the directly connected network is not stub, and
226 thus the valid address space of inbound packets is hard to determine.
227 In this case, IAL can only safely drop the inbound packets whose
228 source addresses belong to the local network. It is very ineffective
229 since the address space size of the local network very small compared
230 to the entire routable address space. To summize, IAL provides low
231 deployment incentives in all cases. If well maintained, false
232 positives can also be avoided. IAL can be implemented using the
233 existing functions on routers (access control lists, ACLs), and thus
234 do not require additional investment. Overall, the deployment cost
235 is low except in the "stub-network" scenario, where the address space
236 of all stubs need to be carefully maintained, which may require heavy
237 manual configuration if there are many directly connected stub
238 networks.
240 3.2. Strict/feasible RPF
241 Strict and feasible RPF can adapt themselves to the routing dynamics
242 and determine the incoming directions of source prefixes
243 automatically. They are more effective than IAL in detecting and
244 filtering spoofing traffic, and thus provide higher deployment
245 incentives to the ISPs. However, they often drop legitimate packets
246 under routing asymmetry, which is very prevalent with the existence
247 of local routing policies, multi-homing and traffic engineering.
248 This makes strict and feasible very risky [NANOG-Risk], and hence the
249 operation needs to be very careful. Feasible RPF has lower FP than
250 strict RPF, since it can apply multiple interfaces as acceptable
251 incoming directions for a source prefix. But feasible RPF cannot
252 avoid all FP in practice, since currently there is no practical way
253 to generate and configure all possible incoming directions in the
254 routers. For example, in a link-state routing environment (IS-IS or
255 OSPF), equal-cost multi-path (ECMP) [ECMP] is often used to generate
256 the multiple acceptable incoming directions. However, in practice,
257 there can be many (tens of) ECMPs for a prefix, but the
258 implementation of a router can only store several (e.g., 4 or 8) of
259 them. Thus, the ECMPs for the prefix installed in the forwarding
260 table may be different in different routers, which eventually causes
261 the FP of feasible RPF. And in BGP, the directions where BGP
262 announcements for a source address prefix have been received can be
263 considered as acceptable incoming directions [IDPF]. However, an ISP
264 may choose not to announce a prefix via a path but still send traffic
265 through it due to its local routing policy. In this case, feasible
266 RPF also causes FP. The basic function of strict and feasible RPF is
267 supported in most modern routers. So deploying them doesn't require
268 investment on upgrading devices.
270 3.3. Loose RPF*
272 Instead of validating the incoming direction of a source address,
273 loose RPF* only checks the existence of the source address in the
274 forwarding table. Loose RPF* is only useful for filtering Martian
275 addresses and unroutable addresses. However, sophisticated attackers
276 can evade loose RPF* checking by simply using routable source
277 addresses. Thus the incentive to deploy loose RPF is low. On the
278 other hand, its operational risk is also low. Loose RPF* is also
279 available in most modern routers, making it cheap to deploy.
281 3.4. Other Reasons
283 There are other reasons why the deployment of ingress filtering
284 hasn't been improved in four years. First, although most modern
285 routers are capable of ingress filtering, some legacy routers are
286 incapable [NANOG-Equipment]. Hence, even at the locations where no
287 risk exists (e.g. stub or single-homed networks), ingress filtering
288 may not be applied. Another reason is called inertia. Since ingress
289 filtering is not enabled on routers by default, some network
290 administrators just won't bother to turn it on
291 [NANOG-PowerOfDefaults].
293 4. Discussion
295 In this section, we discuss the directions that we can explore to
296 improve SAVI-BF. We briefly survey two categories of SAVI-BF
297 proposals, path based techniques and end-to-end based techniques. We
298 discuss their requirements, advantages and disadvantages. We only
299 focus on the techniques that are implemented on the routers. The
300 techniques implemented on end hosts, such as [IPSec], [HCF] and
301 [IP-Puzzles], are not covered here.
303 4.1. Path based Techniques
305 The path based techniques essentially require that a router R knows
306 the forwarding paths that each source prefix S uses toward its
307 destinations, and subsequently knows the incoming directions/
308 interfaces of S. Sometimes, this information is available to R. For
309 example, in a pure link-state routing protocol environment (e.g., IS-
310 IS, OSPF), all nodes have the same view of the network. Thus, R can
311 compute the paths from S to all destinations, and then infer the
312 incoming directions of S. One exception is that, when there are
313 multiple equally best paths, R may not determine which one S will
314 use. On the other hand, if a distance-vector (e.g., RIP) or a path-
315 vector (BGP) routing protocol is used, it is even harder for R to
316 determine the paths of S, since the sufficient routing information is
317 missed. [SAVE] and [IDPF] are tow proposals which validate source
318 addresses by inferring their forwarding paths.
320 4.2. End-to-end based Techniques
322 There are, however, other proposals that don't rely on path
323 information. We call them end-to-end based techniques. For example,
324 [SPM] associates each source prefix (indeed, source AS number) with a
325 key. S, an SPM-enabled AS, will tag the key into outbound packets
326 toward R at its border routers. And R verifies the keys of the
327 inbound packets whose source addresses belong to S at its border
328 routers. The routers will drop a packet if the key is incorrect.
329 Thus, R manages to validate the source addresses of S without knowing
330 its forwarding paths. The end-to-end based the techniques typically
331 need the cooperation between the source and the verification nodes,
332 and require particular tags be carried in the data packets. Further
333 more, even the end-to-end based techniques require to distinguish
334 inbound traffic and outbound traffic, which is not completely path-
335 independent.
337 4.3. Non-technical Proposals
339 There are also proposals which formulate source address validation as
340 an economic problem [FaaS], or suggest that laws and governance
341 should be enforced. These directions, however, may be out of the
342 scope of IETF.
344 5. Acknowledgment
346 The authors would like to thank Fred Baker and Joel M. Halpern for
347 their comments.
349 This document was generated using the xml2rfc tool.
351 6. Informative References
353 [ARBOR-2010]
354 Dobbins, R. and C. Morales, "Network Infrastructure
355 Security Report", February 2010.
357 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering:
358 Defeating Denial of Service Attacks which employ IP Source
359 Address Spoofing", RFC 2827, BCP 38, May 2000.
361 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
362 Networks", RFC 3704, BCP 84, March 2004.
364 [DrDoS-300Gbps]
365 Prince, M., "The DDoS That Almost Broke the Internet",
366 March 2013.
368 [ECMP] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
369 Multicast Next-Hop Selection", RFC 2991, November 2000.
371 [Efficacy]
372 Beverly, R., Berger, A., Hyun, Y., and k. claffy,
373 "Understanding the Efficacy of Deployed Internet Source
374 Address Validation Filtering", August 2009.
376 [FaaS] Liu, B., Bi, J., and X. Yang, "FaaS: Filtering IP Spoofing
377 Traffic as a Service", 2012.
379 [Ground-Truth]
380 Labovitz, C., "Botnets, DDoS and Ground-Truth", October
381 2010.
383 [HCF] Jin, C., Wang, H., and K. Shin, "Hop-count filtering: an
384 effective defense against spoofed DDoS traffic", 2003.
386 [IDPF] Duan, Z., Yuan, X., and J. Ch, "Controlling IP Spoofing
387 Through Inter-Domain Packet Filters", 2008.
389 [IP-Puzzles]
390 Feng, W., Feng, W., and A. Luu, "The Design and
391 Implementation of Network Puzzles", 2005.
393 [IPSec] Kent, S. and K. Seo, "Security Architecture for the
394 Internet Protocol", RFC 4301, December 2005.
396 [MIT-Spoofer]
397 Beverly, R., "Spoofer Project", January 2012,
398 .
400 [NANOG-Equipment]
401 Bicknell, L., "BCP38 Deployment", March 2012, .
404 [NANOG-Helpless]
405 Bulk, F., "Are we really this helpless? (Re: isprime DOS
406 in progress)", January 2009, .
409 [NANOG-PowerOfDefaults]
410 Donelan, S., "BCP38 Deployment", March 2012, .
413 [NANOG-Risk]
414 Gilmore, P., "BCP38 Deployment", March 2012, .
417 [SAVE] Li, J., Mirkovic, J., Wang, M., Reiher, P., and L. Zhang,
418 "SAVE: Source Address Validity Enforcement Protocol",
419 2002.
421 [SPM] Anat, A. and H. Hanoch, "Spoofing Prevention Method",
422 March 2005.
424 Authors' Addresses
426 Jun Bi
427 Tsinghua University
428 Network Research Center, Tsinghua University
429 Beijing 100084
430 China
432 Email: junbi@tsinghua.edu.cn
433 Bingyang Liu
434 Tsinghua University
435 Network Research Center, Tsinghua University
436 Beijing 100084
437 China
439 Email: liubingyang@tsinghua.edu.cn