1: \documentclass[10pt,twocolumn]{IEEEtran}
2: %\documentclass[12pt,draft]{IEEEtran}
3: \usepackage{graphicx}
4: \usepackage{verbatim}
5:
6: \def\labelenumi{\theenumi.} \def\theenumi{\hspace{5mm}\roman{enumi}}
7:
8: \setcounter{page}{1}
9:
10: \begin{document}
11:
12: \title{\Large\bf Active Internet Traffic Filtering:
13: Real-time Response to Denial-of-Service Attacks}
14:
15: \author{Katerina Argyraki \hspace{1cm} David R. Cheriton\\
16: {\it Computer Systems Lab\\
17: Stanford University\\
18: \{argyraki, cheriton\}@dsg.stanford.edu}\\
19: \hspace{1cm} \\
20: Subj-class: Networking and Internet Architecture}
21:
22: \date{}
23: \maketitle
24:
25: \thispagestyle{empty}
26:
27: \renewcommand{\labelitemi}{$-$}
28:
29: \begin{abstract}
30: Denial of Service (DoS) attacks are one of the most challenging threats to
31: Internet security.
32: An attacker typically compromises a large number of vulnerable hosts and uses them
33: to flood the victim's site with malicious traffic,
34: clogging its tail circuit and interfering with normal traffic.
35: At present, the network operator of a site under attack has no other resolution
36: but to respond manually
37: by inserting filters in the appropriate edge routers to drop attack traffic.
38: However, as DoS attacks become increasingly sophisticated,
39: manual filter propagation becomes unacceptably slow or even infeasible.
40:
41: In this paper, we present \emph{Active Internet Traffic Filtering},
42: a new automatic filter propagation protocol.
43: We argue that this system provides a guaranteed, significant level of
44: protection against DoS attacks
45: in exchange for a reasonable, bounded amount of router resources.
46: We also argue that the proposed system cannot be abused by a malicious
47: node to interfere with normal Internet operation.
48: Finally, we argue that it retains its efficiency in the face of continued
49: Internet growth.
50: \end{abstract}
51:
52: \section{Introduction}
53: \label{intro}
54:
55:
56: Denial of Service (DoS) attacks are recognized as one of the most
57: challenging threats to Internet security.
58: Any organization or enterprise that is dependent on the Internet
59: can be subject to a DoS attack,
60: causing its service to be severely disrupted, if not fail completely.
61: The attacker typically uses a worm to create an ``army'' of zombies,
62: which she orchestrates to flood the victim's site with malicious traffic.
63: This malicious traffic exhausts the victim's resources,
64: thereby seriously affecting the victim's ability to respond to normal traffic.
65:
66: A network layer solution is required because the end-user or end-organization
67: has no way to protect its tail circuit from being congested by an attack,
68: causing the disruption sought by the attacker.
69: For example, if an enterprise has a $10$ Mbps connection to the Internet,
70: an attacker can command its zombies to send traffic far exceeding this $10$ Mbps
71: rate to this enterprise,
72: completely congesting the downstream link to the enterprise
73: and causing normal traffic to be dropped.
74:
75: Network operators use conventional router filtering capabilities to respond to DoS attacks.
76: Typically, an operator of a site under attack identifies the nature of the
77: packets being used in the attack by some packet collection facility,
78: installs a filter in its firewall/edge router to block these packets
79: and then requests its ISP to install comparable filters in its routers
80: to remove this traffic from the tail circuit to the site.
81: Each ISP can further communicate with its peering ISPs to block this unwanted
82: traffic as well, if it so desires.
83:
84: Currently, this propagation of filters is manual:
85: the operator on each site determines the necessary filters
86: and adds them to each router configuration.
87: In several attacks,
88: the operators of different networks have been forced to communicate by
89: telephone given that the network connection, and thus email, was inoperable
90: because of the attack.
91:
92: As DoS attacks become increasingly sophisticated,
93: manual filter propagation becomes unacceptably slow or even infeasible.
94: For example, an attack can switch from one protocol to another,
95: move between source networks as well as oscillate between on and off
96: far faster than any human can respond.
97: In general, network operators are confronting an ``arms race'' in which
98: any defense, such as manually installed filters,
99: is viewed as a challenge by the community of attacker-types to defeat.
100: Exploiting a weakness such as human speeds of filter configuration
101: is an obvious direction for an attacker to pursue.
102:
103: The concept of automatic filter propagation has already been introduced in
104: \cite{Mahajan01}: a router is configured with a filter to drop (or rate-limit)
105: certain traffic; if it continues to drop a significant amount of this traffic,
106: it requests that the upstream router take over and block the traffic.
107: However, the crucial issues associated with automatic filter propagation
108: are still unaddressed.
109:
110: The real problem is how to efficiently manage the bounded number of
111: filters available to a network operator to provide this filtering support.
112: An attacker can change protocols, source addresses, port numbers, etc.
113: requiring a very large number of filters.
114: However, a sophisticated hardware router has a fixed maximum number of
115: wire-speed filters that can block traffic with no degradation
116: in router performance.
117: The maximum is determined by hardware table sizes
118: and is typically limited to several thousand.
119: A software router is typically less constrained by table space,
120: but incurs a processing overhead for each additional filter.
121: This usually limits the practical number of filters to even less than
122: a hardware router.
123: Moreover, there is a processing cost at each router for installing each new
124: filter, removing the old filters and sending and receiving filter
125: propagation protocol messages.
126:
127: Given the restricted amount of filtering resources available to each router,
128: hop-by-hop filter propagation towards the attacker's site clearly does not scale:
129: Internet backbone routers would quickly become the ``filtering bottleneck''
130: having to satisfy filtering requests coming from all the corners of the Internet.
131: Fortunately, traceback \cite{Savage00} \cite{Snoeren01}
132: makes it possible to identify a router close to the attacker
133: and send it a filtering request directly.
134: However, any filter propagation mechanism other than hop-by-hop raises a serious
135: security issue:
136: Once a router starts accepting filtering requests from unknown sources,
137: how can it trust that these requests are not forged by malicious nodes
138: seeking to disrupt normal communication between other nodes?
139:
140: In this paper we propose a new filter propagation protocol called AITF
141: (Active Internet Traffic Filtering):
142: The victim sends a filtering request to its network gateway.
143: The victim's gateway temporarily blocks the undesired traffic,
144: while it propagates the request to the attacker's gateway.
145: As we will see,
146: the protocol both motivates and assists the attacker's gateway to block
147: the attack.
148: Moreover, a router receiving a filtering request satisfies it
149: only if it determines that the requestor is on the same path with
150: the specified undesired traffic.
151: Thus, the filter cannot affect any nodes in the Internet
152: other than those already operating at the mercy of the requestor.
153:
154: The novel aspect of AITF is that it enables each participating
155: service provider to guarantee to its clients a \emph{specific, significant amount
156: of protection against DoS attacks},
157: while it requires only a \emph{bounded credible amount of resources}.
158: At the same time it is \emph{secure} i.e., it cannot be abused by a malicious
159: node to harm (e.g. block legitimate traffic to) other nodes.
160: Finally, it \emph{scales with Internet size} i.e., it keeps its efficiency
161: in the face of continued Internet growth.
162:
163: \section{Active Internet Traffic Filtering (AITF)}
164: \label{aitf}
165:
166: \subsection{Terminology}
167:
168: A \emph{flow label} is a set of values that captures the common characteristics
169: of a traffic flow --
170: e.g., ``all packets with IP source address $S$ and IP destination address $D$''.
171:
172: A \emph{filtering request} is a request to block a flow of packets --
173: all packets matching a specific wildcarded flow label -- for the next
174: $T$ time units.
175:
176: A \emph{filtering contract} between networks $A$ and $B$ specifies:
177: \begin{enumerate}
178: \item{The filtering request rate $R_{1}$ at which $A$ accepts filtering
179: requests to block certain traffic to $B$.}
180: \item{The filtering request rate $R_{2}$ at which $A$ can
181: send filtering requests to get $B$ to block certain traffic from coming into $A$.}
182: \end{enumerate}
183:
184: An \emph{AITF network} is an Autonomous Domain which has a filtering contract
185: with each of its end-hosts and each neighbor Autonomous Domain directly connected to it.
186: An \emph{AITF node} is either an end-host or a border router
187: \footnote{A \emph{border router} is a router that has interfaces in more
188: than one AITF networks.}
189: in an AITF network.
190:
191: Finally, we define the following terms with respect to an undesired flow:
192: The \emph{attack path} is the set of AITF nodes the undesired flow goes through.
193: The \emph{attacker} is the origin of the undesired flow.
194: The \emph{victim} is the target of the undesired flow.
195: The \emph{attacker's gateway} is the AITF node closest to the attacker
196: along the attack path.
197: Similarly, the \emph{victim's gateway} is the AITF node closest to the victim
198: along the attack path.
199:
200: \subsection{Overview}
201: \label{overview}
202:
203: The AITF protocol enables a service provider to protect a client
204: against $N$ undesired flows,
205: by using only $n\ll N$ filters and a DRAM cache of size $O(N)$.
206: The motivation is that each router can afford gigabytes of DRAM
207: but only a limited number of filters.
208:
209: In an AITF world,
210: each Autonomous Domain (AD) is an AITF network
211: i.e., it has filtering contracts with all its end-hosts and peering ADs.
212: These contracts limit the rates by which the AD can send/receive
213: filtering requests to/from its end-hosts and peering ADs.
214: The limited rates allow the receiving router to police the requests to the specified rates
215: and indiscriminately drop requests when the rate is in excess of the agreed rate.
216: Thus, the router can limit the CPU cycles used to process filtering requests
217: as well as the number of filters it requires.
218:
219: An AITF filtering request is initially sent from the victim to
220: the victim's gateway;
221: the victim's gateway propagates it to the attacker's gateway;
222: finally, the attacker's gateway propagates it to the attacker.
223: Both the victim's gateway and the attacker's gateway install filters to block
224: the undesired flow.
225: The victim's gateway installs a filter only temporarily, to immediately
226: protect the victim, while it waits for the attacker's gateway to take responsibility.
227: The attacker's gateway is expected to install a filter and block the undesired flow for
228: $T$ time units.
229:
230: If the undesired flow stops within some grace period,
231: the victim's gateway interprets this as a hint that the attacker's gateway
232: has taken over and removes its temporary filter.
233: This leaves the door open to ``on-off'' undesired flows
234: \footnote{When the attacker's gateway does not cooperate,
235: the attacker can start an undesired flow, stop long enough to trick the victim's gateway into
236: removing its temporary filter, then start again and so on.}.
237: In order to detect and block such ``on-off'' flows,
238: the victim's gateway needs to remember each
239: filtering request for at least $T$ time units.
240: Thus, the victim's gateway, installs a filter for $T_{tmp} \ll T$ time units,
241: but keeps a ``shadow'' of the filter in DRAM for $T$ time units
242: \footnote{
243: Keeping each filter for $T$ time units is very expensive --
244: doing so would defeat the whole purpose of pushing filtering to the attacker's gateway.}.
245:
246: The attacker's gateway expects the attacker to stop the undesired flow within a grace period.
247: Otherwise, it holds the right to disconnect from her.
248: This fact encourages the attacker to stop the undesired flow.
249: Similarly, the victim's gateway expects the attacker's gateway to block the
250: undesired flow within a grace period.
251: Otherwise, the mechanism \emph{escalates}:
252: The victim's gateway now plays the role of the victim
253: (i.e., it sends a filtering request to its own gateway)
254: and the attacker's gateway plays the role of the attacker
255: (i.e., it is asked to stop the undesired flow or risk disconnection).
256: The escalation process should become clear with the example in
257: \ref{example}.
258:
259: Thus, the mechanism proceeds in \emph{rounds}.
260: At each round, only four nodes are involved.
261: In the first round,
262: the mechanism tries to push filtering of undesired traffic back to
263: the AITF node closest to the attacker.
264: If that fails, it tries the second closest AITF node to the attacker and so on.
265:
266: \subsection{Basic protocol}
267: \label{protocol}
268:
269: The AITF protocol involves only one type of message: a \emph{filtering request}.
270: A filtering request contains a \emph{flow label} and a \emph{type} field.
271: The latter specifies whether this request is addressed to the victim's gateway,
272: the attacker's gateway or the attacker.
273:
274: The only nodes in an AITF network that speak the AITF protocol are end-hosts
275: and border routers. Internal routers do not participate.
276:
277: AITF node $X$ sends a filtering request to AITF node $Y$,
278: when $X$ wants a certain traffic flow coming through $Y$ to be blocked
279: for $T$ time units.
280:
281: When AITF node $Y$ receives a filtering request,
282: it checks which end-host or peering network the request is received
283: from/through.
284: If that end-host or peering network has exceeded its allowed rate,
285: the request is dropped.
286: If not, $Y$ looks at the specified undesired flow label and takes certain actions:
287: \begin{itemize}
288: \item{If $Y$ is the victim's gateway:
289: \begin{enumerate}
290: \item{It installs a \emph{temporary} filter to block the undesired flow for
291: $T_{tmp} \ll T$ time units.}
292: \item{It logs the filtering request in DRAM for $T$ time units.}
293: \item{It propagates the filtering request to the attacker's gateway.
294: If the attacker's gateway does not block the flow within $T_{tmp}$ time units,
295: $Y$ propagates the filtering request to its own gateway.}
296: \end{enumerate}
297: }
298: \item{If $Y$ is the attacker's gateway:
299: \begin{enumerate}
300: \item{It installs a filter to block the undesired flow for $T$ time units.}
301: \item{It propagates the filtering request to the attacker.
302: If the attacker does not stop the flow within a grace period,
303: $Y$ disconnects from her.}
304: \end{enumerate}
305: }
306: \item{If $Y$ itself is the attacker, it stops the flow (to avoid disconnection).}
307: \end{itemize}
308:
309: We should note that the behavior described above is that of a non-compromised,
310: non-malicious node.
311: Neither the attacker not even the attacker's gateway
312: are expected to always conform to this behavior.
313: AITF operation does not rely on their cooperation.
314:
315: \subsection{Example}
316: \label{example}
317:
318: \begin{figure}[htbp]
319: \begin{center}
320: \resizebox{7cm}{!}{\includegraphics{./filtering.eps}}
321: \caption{Example attack path from attacker $B\_host$ to victim $G\_host$}
322: \label{filterfig}
323: \end{center}
324: \end{figure}
325:
326: In Figure \ref{filterfig} $G\_host$ -- which stands for ``good host'' -- is an end-host
327: residing in enterprise network $G\_net$,
328: which is connected to local ISP $G\_isp$ through router $G\_gw1$.
329: $G\_isp$ runs a regional network that connects through its backbone router
330: $G\_gw2$ to a wide-area ISP $G\_wan$.
331: Similarly, $B\_host$ -- which stands for ``bad host'' -- is an end-host residing in
332: enterprise network $B\_net$ etc.
333:
334: $B\_host$ starts sending an undesired flow to $G\_host$.
335: $G\_host$ sends a filtering request to $G\_gw1$ against $B\_host$.
336: Upon reception of $G\_host$'s request, $G\_gw1$ temporarily blocks
337: the undesired flow but also propagates the request to $B\_gw1$.
338:
339: On the other side, upon reception of $G\_gw1$'s request,
340: $B\_gw1$ immediately blocks the undesired flow,
341: but also propagates the filtering request to $B\_host$.
342: $B\_host$ either stops the undesired flow or risks being disconnected.
343: Thus, if $B\_gw1$ cooperates,
344: by the end of the first round,
345: filtering of the undesired flow has been successfully pushed to the AITF
346: node closest to the attacker ($B\_gw1$).
347:
348: Of course, $B\_gw1$ may decide not to cooperate and ignore the filtering request.
349: Then, the mechanism escalates:
350: $G\_gw1$ propagates the filtering request to $G\_gw2$.
351: $G\_gw2$ temporarily blocks all undesired traffic,
352: but also propagates the filtering request to $B\_gw2$ and so on.
353: Thus, if $B\_gw2$ cooperates,
354: by the end of the second round,
355: filtering of the undesired flow has been successfully pushed to the
356: second closest to the attacker AITF node ($B\_gw2$).
357:
358: In the worst-case scenario, even $B\_gw3$ refuses to cooperate.
359: As a result, $G\_gw3$ disconnects from $B\_gw3$.
360:
361: \subsection{Verifying a filtering request}
362: \label{handshake}
363:
364: In a network architecture where source address spoofing is allowed,
365: compromised node $M$ can maliciously request the blocking of traffic
366: from $A$ to $V$ thereby disrupting their communication.
367: To avoid this, we add a simple extension to the basic protocol.
368:
369: The extension introduces two more messages:
370: A \emph{verification query} and a \emph{verification reply}.
371: Both types include a \emph{flow label} and a \emph{nonce} (i.e., a random number).
372:
373: When router $Y$ receives a filtering request,
374: which asks for the blocking of a traffic flow from attacker $A$ to victim $V$,
375: $Y$ verifies that the request is real before taking any action to satisfy it.
376: If $Y$ is the victim's gateway,
377: this verification is trivial with appropriate ingress filtering.
378: If $Y$ is the attacker's gateway,
379: verification is accomplished through the following ``3-way handshake'':
380:
381: \begin{enumerate}
382: \item{Router $Y$ receives a filtering request,
383: asking for the blocking of a traffic flow from attacker $A$ to victim $V$.}
384: \item{$Y$ sends a verification query to $V$,
385: asking ``Do you really not want this traffic flow?''}
386: \item{$V$ responds to $Y$ with a verification reply.
387: The reply must include the same flow label and nonce included in the query.
388: }
389: \end{enumerate}
390: If the nonce on $V$'s reply is the same with the nonce on $Y$'s query,
391: $Y$ accepts the request as real and proceeds to satisfy it.
392: The ``3-way handshake'' is further discussed in \ref{secure}.
393:
394: \subsection{Assumptions}
395: \label{assumptions}
396:
397: AITF operation assumes that the victim's gateway can determine
398: \begin{itemize}
399: \item{Who is the attacker's gateway (in order to propagate the request).}
400: \item{Who is the next AITF node on the attack path (in order to escalate, if necessary).}
401: \end{itemize}
402: These assumptions are met, if an efficient traceback technique as those described in
403: \cite{Savage00} \cite{Snoeren01} is available.
404:
405: Also AITF assumes that off-path traffic monitoring is not possible
406: i.e., if node $M$ is not located on the path from node $A$ to node $V$,
407: then $M$ cannot monitor traffic sent on that path
408: (this assumption is necessary for the ``3-way handshake'').
409:
410: \section{Discussion}
411: \label{discussion}
412:
413: \subsection{Why it works}
414: \label{work}
415:
416: The basic idea of AITF is to push filtering of undesired traffic to
417: the network closest to the attacker.
418: That is, hold a service provider responsible for providing connectivity to a
419: misbehaving client and have it do the dirty job.
420: The question is, why would the attacker's service provider accept
421: (or at least be encouraged) to do that?
422:
423: If the attacker's service provider does not cooperate,
424: it risks being disconnected by its own service provider.
425: This makes sense for both of them:
426: If $B\_net$ in Figure \ref{filterfig} refuses to block its misbehaving client,
427: the filtering burden falls on $B\_isp$.
428: Thus, it makes sense for $B\_isp$ to consider $B\_net$ a bad client and disconnect from it.
429: On the other hand, this offers an incentive to $B\_net$ to cooperate
430: and block the undesired flow.
431: Otherwise, it will be disconnected by $B\_isp$,
432: which will result in all of its clients being dissatisfied.
433:
434: Moreover, AITF offers an economic incentive to providers to protect their network
435: from the inside by employing appropriate ingress filtering.
436: If a provider pro-actively prevents spoofed flows from exiting its network,
437: it lowers the probability of an attack being launched from its own network,
438: thus reducing the number of expected filtering requests it will later have
439: to satisfy to avoid disconnection.
440:
441: In short, AITF creates a cost vs quality trade-off for service providers:
442: Either they pay the cost to block the undesired flows generated by their few bad clients,
443: or they run the risk of dissatisfying their legitimate clients,
444: which are the vast majority.
445: Thus, the quality of a provider's service is now related to its capability to filter its
446: own misbehaving clients.
447:
448: \subsection{Why it is secure}
449: \label{secure}
450:
451: The greatest challenge with automatic filtering mechanisms is that
452: compromised node $M$ may maliciously request the blocking of traffic from $A$ to $V$,
453: thereby disrupting their communication.
454: AITF prevents this through the ``3-way handshake'' described in \ref{handshake}.
455:
456: The ``3-way handshake'' does not exactly verify the authenticity of a filtering request.
457: It only enables $A$'s gateway to verify that a request to block traffic
458: from $A$ to $V$ has been sent by a node located on the path from $A$ to $V$.
459: A compromised router located on this path can naturally forge and snoop
460: handshake messages to disrupt $A$-$V$ communication.
461: However, such a compromised router can disrupt $A$-$V$ communication anyway,
462: by simply dropping the corresponding packets.
463: \footnote{We assumed that off-path traffic monitoring is impossible.
464: Thus, an off-path malicious node cannot snoop handshake messages.}
465:
466: In short, AITF cannot be abused by a compromised node to cause interruption
467: of a legitimate traffic flow,
468: unless that compromised node is responsible for routing the flow,
469: in which case it can interrupt the flow anyway.
470:
471: \subsection{Why it scales}
472: \label{scale}
473:
474: AITF scales with Internet size,
475: because it pushes filtering of undesired traffic to the leaves of the Internet,
476: where filtering capacity follows Internet growth.
477:
478: In most cases,
479: AITF pushes filtering of undesired traffic to the provider(s) of the attacker(s).
480: Thus, the amount of filtering requests a provider is asked to satisfy
481: grows proportionally to the number of the provider's (misbehaving) clients.
482: However, intuitively, a provider's filtering capacity also grows proportionally
483: to the number of its clients.
484: \footnote{In the AITF model, the filtering contract becomes part of a provider's services.
485: Thus, a part of each client's service fee is invested in provisioning the provider's routers
486: with extra filters.}
487: In short, a provider's filtering capacity follows the provider's filtering workload.
488:
489: If the attacker's provider is itself compromised,
490: AITF naturally fails to push filtering to it.
491: Instead, filtering is performed by another network, closer to the Internet core.
492: If this situation occurred often, then the scalability argument stated above would be false.
493: Fortunately,
494: compromised routers are a very small percentage of the Internet infrastructure.
495: \footnote{It is difficult to compromise a router, because of the limited number of
496: potentially exploitable services it offers.
497: Moreover, service providers have an immense economic incentive to keep their routers
498: uncompromised.}
499: Thus, AITF fails to push filtering to the attacker's provider with a very small
500: probability.
501:
502: \section{Performance Analysis}
503: \label{analysis}
504:
505: In this section we provide simple formulas that describe AITF performance.
506: For lack of space and given that our formulas are very simple and intuitive,
507: we defer any details to \cite{aitf}.
508:
509: \subsection{The victim's perspective}
510: \label{victim}
511:
512: \subsubsection{Effective bandwidth of an undesired flow}
513:
514: AITF significantly reduces the \emph{effective bandwidth} of an undesired flow
515: -- i.e., the bandwidth of the undesired flow actually experienced by the victim.
516: Specifically, it can be shown that AITF reduces the effective bandwidth of an
517: undesired flow by a factor of
518: $$r \approx \frac{n(T_d + T_r)}{T}$$
519: where $n$ is the number of non-cooperating
520: \footnote{
521: By \emph{non-cooperating} node we mean an AITF node, which does not take
522: its responsibility to filter an undesired flow for $T$ time units.
523: }
524: AITF nodes on the attack path,
525: $T_d$ is attack detection time and $T_r$ is the one-way delay from the
526: victim to its gateway.
527: $T$ is the timeout associated with all filtering requests
528: i.e. each filtering request asks for the blocking of a flow for $T$ time units.
529: For example, if the only non-cooperating node on the attack path is the attacker,
530: and if the one-way delay from the victim to its gateway is $T_r = 50$ msec,
531: for $T = 1$ min,
532: an AITF node can reduce the effective bandwidth of an undesired flow by
533: a factor $r \approx 0.00083$.
534: \footnote{
535: $T_d$ may be significant the first time the undesired flow is detected.
536: Here, we ignore that initial overhead.
537: Detecting a reappearing undesired flow could be as fast as matching a received
538: packet header to a logged undesired flow label i.e., insignificant compared
539: to the one-way delay to the victim's gateway.
540: }
541:
542: Here we only demonstrate this result for $n=1$ i.e.,
543: when the only non-cooperating node on the attack path is the attacker:
544: At time $0$ the attacker starts the undesired flow;
545: at time $T_d$ the victim detects it and sends a filtering request;
546: at time $T_d + T_r$ the victim's gateway temporarily blocks the flow
547: and the victim stops receiving it;
548: the flow is eventually blocked by the attacker's gateway and released after
549: time $T$.
550: Thus, if the original bandwidth of the undesired flow is $B$,
551: its effective bandwidth is $B_e \approx B\cdot\frac{T_d + T_r}{T}$.
552:
553: When $n \ge 1$ i.e., when $1$ or more AITF routers close to the attacker
554: are non-cooperating, the attacker can play ``on-off'' games:
555: Pretend to stop the undesired flow to trick the victim's gateway into removing
556: its filter, then resume the flow etc.
557: The victim's gateway detects and blocks such attackers by using its DRAM cache.
558:
559: \subsubsection{Number of undesired flows}
560:
561: An AITF node is guaranteed protection against a specific number of undesired flows,
562: which depends on its contract with its service provider.
563: Specifically, it can be shown that
564: if a client is allowed to send $R_{1}$ filtering requests per time unit
565: to the provider, then the client is protected
566: \footnote{
567: When we say that the client is ``protected'' against an undesired flow,
568: we mean that the client can significantly reduce the effective bandwidth of the flow,
569: as described in the previous subsection.}
570: against
571: $$N_v = R_{1}\cdot T$$
572: simultaneous undesired flows.
573: For example, for $R_1 = 100$ filtering requests per second and $T = 1$ min,
574: the client is protected against $N_v = 6,000$ simultaneous undesired flows.
575:
576: \subsection{Filtering close to the victim}
577: \label{victims_gw}
578:
579: AITF enables a service provider to protect a client against $N_v$ undesired
580: flows by using only $n_v \ll N_v$ filters.
581: Specifically, it can be shown that
582: if a client is allowed to send $R_{1}$ filtering requests per time unit to the provider,
583: the provider needs $n_v$ filters and a DRAM cache that can fit $m_v$ filtering requests
584: in order to satisfy all the requests,
585: where
586: $$n_v = R_{1}\cdot T_{tmp}, \ \ \ m_v = R_{1}\cdot T$$
587: $T_{tmp}$ is the amount of time that elapses from the moment the victim's gateway
588: installs a temporary filter until it removes it.
589: The purpose of the temporary filter is to block the undesired flow until
590: the attacker's gateway takes over.
591: Therefore, $T_{tmp}$ should be large enough to allow
592: the traceback from the victim's gateway to the attacker's gateway
593: plus the 3-way handshake.
594: For example, suppose we use an architecture like \cite{CheritonGritter00},
595: where traceback is automatically provided inside each packet.
596: Then traceback time is $0$.
597: If the 3-way handshake between the two gateways takes $600$ msec,
598: for $R_1 = 100$ filtering requests per second and $T = 1$ min,
599: the service provider needs $n_v = 60$ filters to protect a client
600: against $N_v = 6,000$ undesired flows.
601:
602: \subsection{Filtering close to the attacker}
603: \label{attackers_gw}
604:
605: AITF requires a bounded amount of resources from the attacker's service provider.
606: Specifically,
607: if a service provider is allowed to send $R_{2}$ filtering requests
608: per time unit to a client,
609: then the provider needs $$n_a = R_{2}\cdot T$$ filters in order to ensure that the client
610: satisfies all the requests.
611: Given these resources, the provider can filter $N_a = n_a = R_{2}\cdot T$
612: simultaneous undesired flows generated by the client.
613: For example, for $R_2 = 1$ filtering request per second and $T = 1$ min,
614: the provider needs $n_a = 60$ filters for the client.
615: This filtering request rate allows the provider to filter up to $N_a = 60$
616: simultaneous undesired flows generated by the client.
617:
618: \subsection{The attacker's perspective}
619: \label{attacker}
620:
621: We have defined an attacker as the source of an undesired flow.
622: By this definition, an attacker is not necessarily a malicious/compromised node;
623: it is simply a node being asked to stop sending a certain flow.
624: A legitimate AITF node must be provisioned to stop sending undesired flows
625: when requested, in order to avoid disconnection.
626:
627: AITF requires a bounded amount of resources from the attacker as well.
628: Specifically,
629: if a service provider is allowed to send $R_{2}$ filtering requests
630: per time unit to a client,
631: the client needs $$n_a = R_{2}\cdot T$$ filters
632: (as many as the provider) in order to satisfy all the requests.
633: For example, for $R_2 = 1$ filtering request per second and $T = 1$ min,
634: the client needs $n_a = 60$ filters.
635:
636: \section{Related Work}
637: \label{related}
638:
639: In \cite{Mahajan01} Mahajan {\it et al.} propose mechanisms for detecting and
640: controlling high bandwidth traffic aggregates.
641: One part of their work discusses how a node determines whether it is congested
642: and how it identifies the aggregate(s) responsible for the congestion.
643: In contrast, we start from the point where the node has identified the undesired flow(s).
644: In that sense, their work and our work are complementary.
645: Another part of their work discusses how much to rate-limit an annoying aggregate
646: due to a DoS attack or a flash crowd.
647: In contrast,
648: our mechanism focuses on DoS attack traffic and attempts to limit it to rate $0$.
649: \footnote{
650: We believe that DoS attacks should be addressed separately from flash crowds:
651: Flash crowd aggregates are created by legitimate traffic.
652: Therefore, it makes sense to rate-limit them instead of completely blocking them.
653: On the contrary, DoS attack traffic aims at disrupting the victim's operation.
654: Therefore, it makes sense to block it.
655: Blocking a traffic flow is simpler and cheaper than rate-limiting it.
656: Moreover, DoS attack traffic is generated by malicious/compromised nodes.
657: Therefore, it demands a more intelligent defense mechanism.
658: }
659:
660: The part of their work most related to ours proposes a cooperative {\it pushback} mechanism:
661: A congested node attempts to rate-limit an aggregate by dropping a portion of its packets.
662: If the drop rate remains high for several seconds,
663: the node considers that it has failed to rate-limit the aggregate and
664: asks its adjacent upstream routers to do it.
665: If the recipient routers also fail to rate-limit the aggregate,
666: they recursively propagate pushback further upstream.
667:
668: A pushback request is propagated hop by hop by the victim towards the attacker.
669: In contrast, the propagation of an AITF filtering request involves only $4$ nodes:
670: the victim, the victim's gateway, the attacker's gateway and the attacker --
671: we claim that this allows AITF to scale with Internet size.
672: A pushback request does not force the recipient router to rate-limit the problematic
673: aggregate; it relies on its good will to cooperate.
674: In contrast,
675: AITF forces the attacker to discontinue the undesired flow
676: and the attacker's service provider to filter the attacker
677: or else risk disconnection --
678: we claim that this makes AITF deployable.
679:
680: In \cite{ParkLee01} Park and Lee propose DPF (Distributed Packet Filtering),
681: a distributed ingress-filtering mechanism for pro-actively blocking spoofed flows.
682: In contrast, AITF aims at blocking \emph{all} undesired -- including spoofed -- flows
683: as close as possible to their sources. Thus, it cannot be replaced by DPF.
684: On the other hand, DPF blocks most spoofed flows \emph{before} they reach their destination
685: i.e., DPF is proactive, whereas AITF is reactive.
686: In that sense, DPF and AITF are complementary.
687:
688: In \cite{Keromytis02} Keromytis {\it et al.} propose SOS (Secure Overlay Services),
689: an architecture for pro-actively protecting against DoS attacks
690: the communication between a pre-determined location
691: and a specific set of users who have authorized
692: access to communicate with that location.
693: In contrast, AITF addresses the more general problem of protecting
694: against DoS attacks any location accessible to all Internet users.
695:
696: Finally, \cite{Savage00} and \cite{Snoeren01}
697: propose traceback solutions i.e., mechanisms that enable a victim to
698: reconstruct the path followed by attack packets in the face of source address
699: spoofing.
700: As already mentioned, an efficient traceback mechanism is necessary to AITF
701: operation.
702:
703: \section{Conclusions}
704: \label{conclusions}
705:
706: We presented AITF, an automatic filter propagation mechanism,
707: according to which each Autonomous Domain (AD) has a filtering contract with each
708: of its end-hosts and neighbor ADs.
709: A filtering contract with a neighbor provides a guaranteed, significant level of
710: protection against DoS attacks coming through that neighbor
711: in exchange for a reasonable, bounded amount of router resources.
712:
713: Specifically:
714: \begin{itemize}
715: \item{Given a filtering contract between a client and a service provider,
716: which allows the client to send $R_1$ filtering requests per time unit to the provider,
717: the provider can protect the client against a large number of undesired flows
718: $N_v = R_1 \cdot T$,
719: by significantly limiting the effective bandwidth of each undesired flow.
720: The provider achieves this by using only a modest number of filters
721: $n_v = R_1 \cdot T_{tmp} \ll N_v$.}
722: \item{Given a filtering contract between a client and a service provider,
723: which allows the provider to send $R_2$ filtering requests per time unit to the client,
724: both the client and the provider need a bounded number of filters $n_a = R_2 \cdot T$
725: to honor their contract.}
726: \end{itemize}
727:
728: We argued that AITF successfully deals with the biggest challenge
729: to automatic filtering mechanisms: source address spoofing.
730: Namely, we argued that it is not possible for any malicious/compromised node
731: to abuse AITF in order to interrupt a legitimate traffic flow,
732: unless the compromised node is responsible for routing that flow,
733: in which case it can interrupt the flow anyway.
734:
735: Finally, we argued that AITF scales with Internet size,
736: because it pushes filtering of undesired traffic to
737: the service providers of the attackers,
738: unless the service providers are themselves compromised.
739: Fortunately, compromised routers are a very small percentage of Internet
740: infrastructure.
741: Thus, in the vast majority of cases, AITF pushes filtering of undesired traffic to the
742: leaves of the Internet, where filtering capacity follows Internet growth.
743:
744: %\bibliographystyle{alpha}
745: %\bibliography{/home/katerina/triad/papers/filtering-2/tech/references}
746:
747: \begin{thebibliography}{SWKA00}
748: \newcommand{\etalchar}[1]{$^{#1}$}
749:
750: \bibitem[AC03]{aitf}
751: Katerina Argyraki and David Cheriton.
752: \newblock Active internet traffic filtering, 2003.
753: \newblock http://www.stanford.edu/$\sim$argyraki/misc/longaitf.pdf.
754:
755: \bibitem[CG00]{CheritonGritter00}
756: David~R. Cheriton and Mark Gritter.
757: \newblock Triad: a scalable deployable nat-based internet architecture.
758: \newblock Technical report, January 2000.
759:
760: \bibitem[KMR02]{Keromytis02}
761: Angelos Keromytis, Vishal Misra, and Dan Rubenstein.
762: \newblock Sos: Secure overlay services.
763: \newblock In {\em Proceedigns of ACM SIGCOMM 2001}, Pittsburgh, Pennsylvania,
764: USA, August 2002.
765:
766: \bibitem[MBF{\etalchar{+}}01]{Mahajan01}
767: R.~Mahajan, S.~Bellovin, S.~Floyd, J.~Ioannidis, V.~Paxson, and S.~Schenker.
768: \newblock Controlling high bandwidth aggregates in the network.
769: \newblock Technical report, December 2001.
770:
771: \bibitem[PL01]{ParkLee01}
772: Kihong Park and Heejo Lee.
773: \newblock On the effectiveness of route-based packet filtering for distributed
774: dos attack prevention in power law internets.
775: \newblock In {\em Proceedigns of ACM SIGCOMM 2001}, San Diego, California, USA,
776: August 2001.
777:
778: \bibitem[SPS{\etalchar{+}}01]{Snoeren01}
779: Alex~C. Snoeren, Craig Partridge, Luis~A. Sanchez, Christine~E. Jones, Fabrice
780: Tchakountio, Stephen~T. Kent, and W.~Timothy Strayer.
781: \newblock Hash-based ip traceback.
782: \newblock In {\em Proceedigns of ACM SIGCOMM 2001}, San Diego, California, USA,
783: August 2001.
784:
785: \bibitem[SWKA00]{Savage00}
786: Stefan Savage, David Wetherall, Anna Karlin, and Tom Anderson.
787: \newblock Practical network support for ip traceback.
788: \newblock In {\em Proceedigns of ACM SIGCOMM 2000}, Cambridge, Massachusetts,
789: USA, August 2000.
790:
791: \end{thebibliography}
792:
793: \end{document}
794: