A SIFF: Stateless Internet Flow Filter to Mitigate DDoS Flooding Attacks
Abraham Yaar Adrian Perrig Dawn Song Carnegie Mellon University {ayaar, perrig, dawnsong}@cmu.edu
Abstract
One of the fundamental limitations of the Internet is the inability of a packet ow recipient to halt disruptive ows before they consume the recipients network link resources. Critical infrastructures and businesses alike are vulnerable to DoS attacks or ash-crowds that can incapacitate their networks with trafc oods. Unfortunately, current mechanisms require per-ow state at routers, ISP collaboration, or the deployment of an overlay infrastructure to defend against these events. In this paper, we present SIFF, a Stateless Internet Flow Filter, which allows an end-host to selectively stop individual ows from reaching its network, without any of the common assumptions listed above. We divide all network trafc into two classes, privileged (prioritized packets subject to recipient control) and unprivileged (legacy trafc). Privileged channels are established through a capability exchange handshake. Capabilities are dynamic and veried statelessly by the routers in the network, and can be revoked by quenching update messages to an offending host. SIFF is transparent to legacy clients and servers, but only updated hosts will enjoy the benets of it.
1 Introduction
Despite a signicant breadth of research into defenses, Denial of Service (DoS) attacks remain a signicant problem in the Internet today. The DoS phenomenon has evolved rapidly over the last decade. DoS attacks were
This research was supported in part by the Center for Computer and Communications Security at Carnegie Mellon under grant DAAD19-021-0389 from the Army Research Ofce, and by gifts from Bosch, Cisco, Intel, and Matsushita Electric Works Ltd. The views and conclusions contained here are those of the authors and should not be interpreted as necessarily representing the ofcial policies or endorsements, either express or implied, of ARO, Bosch, Carnegie Mellon University, Cisco, Intel, Matsushita Electric Works Ltd., or the U.S. Government or any of its agencies.
once caused by only a few attackersoften only a single attackersending specially crafted packets designed to exploit aws in the victims particular TCP/IP implementation (e.g., the Teardrop or Land Attack), and sometimes using IP spoong [10] (the forging of the source IP address eld in the IP header to something other than the sending hosts IP address) to hide their identity. DoS attacks are becoming an increasing risk, as the sophistication of current attack tools enables relatively inexperienced attackers to perform these attacks. As the number of systems connected to the Internet has increased, the black-hat community has developed tools (known as root-kits) that take advantage of security aws in operating system services to compromise computers. The black-hat community has also written tools designed to control and coordinate these exploited machines (often called zombies) on a large scale [13, 14]. These developments have given rise to a new type of DoS classication: the distributed DoS attack (DDoS). These attacks tend to be different from simple DoS attacks in that the attacks are composed of compromised hosts that are not easily traceable to the machine controllers themselves. For this reason, DDoS attackers are not concerned with spoong as a disguising tactic; they merely use it to bypass potential IP address lters or to involve unwitting third parties in the attack as trafc ampliers [34]. Furthermore, because of the sheer number of hosts involved, (there have been reports of groups claiming over 140,000 compromised hosts under their control [11]), the attacks tend to work simply by ooding packets onto the network, which converge upstream from the intended victim and disrupt the infrastructure, to prevent or reduce legitimate access to the victim. The DDoS ooding problem is particularly difcult to defend against, because the very architecture that has fueled the Internets growthreliance on intelligent end-hosts connected by a relatively simple network (the end-to-end principle)is used to the attackers advantage. In this network architecture, any host in the network can send a packet 1
to any destination address (even if the destination does not want to receive the packet), and the destination has no way of stopping those packets before they reach it (or its network). Although many innovative avenues of defense against DoS and DDoS have been explored in the literature (we review some of these in the next section), only a few of the approaches even address the DDoS ooding problem. In this paper, we explore the design issues involved in constructing a system from scratch that solves the DDoS ooding problem by giving a packet receiver control over which packets the network delivers to it.
1.1 Related Work
Several researchers have studied the frequency and nature of Internet DoS attacks [16, 17, 21, 24, 31]. In this section, we review related work in the area of Internet DoS defenses. We distinguish the research into two general areas: defending against IP source address spoong, and defending against bandwidth ooding attacks. We rst discuss research in defenses against source IP address spoong. Ferguson and Senie propose to deploy network ingress ltering to limit spoong of the source IP address [15]. Burch and Cheswick propose to use a limited form of DoS attack to probe which links are affected by an attack and can thus trace back to the origin [8]. Park and Lee propose a distributed packet ltering (DPF) mechanism against IP address spoong [32]. DPF relies on BGP routing information to detect spoofed IP addresses. Bellovin et al. suggests adding a new type of ICMP message for traceback [6], and Mankin et al. present an improvement to this scheme [28]. Several researchers propose to embed traceback information within the IP packet [2, 12, 19, 26, 35, 38, 43]. Most of these schemes use the 16-bit IP Identication eld to hold traceback information. Routers along the packets path probabilistically mark bits in the IP Identication eld in different ways. While traceback schemes could be used to nd the origins of the attacks, they often require a large number of packets and cannot be used to lter out packets on a per-packet basis. Snoeren et al. propose a mechanism using router state to track the path of a single packet [37]. Their approach enables a victim to trace back a single packet by querying the router state of upstream routers. In earlier work, we propose the Pi marking scheme to enable the victim to detect packets with a spoofed source IP address [47]. Pi is not effective against bandwidth ooding attacks because it relies on victim ltering of DDoS trafc and bandwidth ooding typically causes damage (i.e., dropped packets) upstream from the victim. The IP traceback and spoong defenses we discussed so far, defend against DDoS at the victim of the attack. The research most closely related with our work attempts 2
to defend against network ooding attacks in the network itself. Stone proposes the CenterTrack mechanism, which uses routers capable of input debugging (the ability to determine through which router interface a particular packet was received) that would be virtually connected through IP tunnels to all border routers on a network [42]. When a node in the network comes under attack, the overlay network is activated, and all border routers channel trafc through the overlay routers. These routers would use input debugging to determine from which border router, and hence from which neighbor network, the DDoS trafc is coming from. However, this technique requires that the ISP create the overlay network and perform ltering, and may not be practical for large attacks. Generalized network congestion control is related to DDoS defense. Ioannidis et al. propose Aggregate Congestion Control (ACC)/Pushback, which leverages router support to rate-limit groups of similar packets responsible for congestion, and push lters upstream towards the sources of those packets to preserve network bandwidth [22, 27]. ACC/Pushback requires non-negligible state at routers and faces challenges in attack trafc identication and ISP interoperation. Stoica et al. propose a mechanism for Stateless Fair Queueing (SFQ) in the network core [40]. Their scheme has edge routers maintain per-ow arrival-rate information. Edge routers label packets based on their ows rate information, and core network routers use probabilistic dropping based on the packet labels to fairly distribute bandwidth among ows. SFQ requires that the malicious ows edge routers implement the labeling, so that those ows can be rate limited in the core. Researchers recently investigated using overlay networks to mitigate the effect of DoS attacks. Keromytis et al. designed the Secure Overlay Services (SOS) architecture to proactively defend against DoS attacks [25]. SOS uses an overlay network to authenticate users and installs lters at the ISP level. Anderson generalizes the SOS architecture by considering different ltering techniques and overlay routing mechanisms and proposes Mayday [4]. Adkins et al. propose the use of the Internet Indirection Infrastructure (i3) [39] to enable the victim to stop individual ows by removing the unique forwarding pointer that each sender possesses [1]. An advantage of these techniques is that they do not require changing the current Internet infrastructure. However, they assume presence of an overlay infrastructure, they require per-ow state in the overlay network, and they assume updated client and server software and protocols. Mirkovic et al. propose D-Ward, an automated system that detects ooding attacks on a link and automatically installs lters [29]. In their system, the receiver has no control over these lters, and so the receiver has no way of stopping a widely distributed ooding attack or choosing ows
it wants to serve in case of a ash crowd [24]. Jamjoom and Shin propose persistent dropping for dealing with ash crowds [23]. Their drop policy preferentially drops TCP SYN packets in favor of preserving ongoing TCP ows, but does not deal with DoS attacks that may ood with trafc other than TCP SYNs. Our SIFF protocol or a capability-based approach that uses per-ow state can easily be implemented in a secure active network environment [3]. Anderson et al. present a capability-based approach, where a sender rst needs to obtain a capability from the infrastructure to send trafc to a receiver [5]. Their approach is similar to ours, but requires per-ow state at each router. Gligor analyzes various mechanisms for ltering excessive connection establishment requests [18]. Assuming that the network connections are not saturated, he analyzes the waiting time guarantees that various puzzle and client challenge techniques provide and comes to the intriguing conclusion that puzzles are not useful to provide any guarantees of waiting time. In contrast to these previous approaches, the mechanisms we present in this paper provide the victim of a ooding attack (or a server in the case of ash crowds) to select individual trafc ows that it wants to stop, without requiring per-ow state in the network (in fact, without contacting any routers or ISPs), while still enabling legacy clients or servers to communicate with updated servers or clients.
ows before they saturate its network, to provide good performance to the remaining ows. In this paper, we present SIFF, a Stateless Internet Flow Filter that enables an endhost to stop individual trafc ows from reaching it, without keeping per-ow state in the network. Specically, SIFF provides the following properties: Client/Server privileged communication. SIFF allows a client and server to establish a privileged channel over IP whose packets take precedence over nonprivileged packets. Recipient controlled privileged ows. SIFF gives the receiving host of a privileged communication channel the ability to tear-down that channel, and thus stop the ow of packets on the channel from reaching its network. Packets from that channel will get dropped by a router close to the sender with, high probability, and thus these packets will not take up bandwidth resources on a link close to the receiver. Limited spoong of source addresses. Equivalent to ingress lteringthe receiving host of a privileged communication channel can be sure, with high probability, that the packets arriving on that channel were sent by a host on the same network as the host having the source IP address in the packet. No end-host/ISP or inter-ISP cooperation. SIFF does not require end-host signaling of routers or the signaling of routers of one ISP by those of another ISP. No intra-ISP cooperation. SIFF does not require signaling between a single ISPs routers beyond that required for packet routing. Small, constant state at routers. Routers implementing SIFF need only keep a constant amount of state per router interface, independent of the number of privileged channels traversing that router. This is one of the main features of SIFF, as other mechanisms we are aware of require per-ow state at routers to achieve the above properties. Small, per-packet processing at routers. A SIFF router need only execute two equality checks for every privileged packet, or a single hash computation (which can be reduced to a table lookup) for every unprivileged packet, that it forwards. These computations are independent of the number of privileged or unprivileged channels traversing a router. The hashing and equality checks can be done in parallel with the routing table lookup, though in practice the equality checks can serve as a packet lter to prevent extraneous lookups. 3
1.2 Organization
The remainder of our paper is composed as follows: in Section 2 we dene the properties and assumptions that we make in designing SIFF. In Section 3 we present a detailed design of the SIFF system and protocols. In Section 4 we present a model, based on real Internet topologies, to analyze SIFFs performance. In Section 5 we discuss several possible modications and extensions to SIFF. Finally, in Section 6 we conclude the paper.
2 Problem Statement and Assumptions
Several researchers recently report that while the victim is in the best position to detect ooding DDoS attacks, it lacks the means to stop malicious ows in the current Internet architecture [1, 5, 18]. Similarly, ash crowds exhaust the bandwidth on network links and TCP ows mutually prevent each other from achieving high bandwidth [24] (the additive increase when there is no packet loss and multiplicative decrease when there is packet loss causes TCP connections to reduce their bandwidth to a very small amount if packet loss exceeds 5%). Thus, there is the need for a mechanism that enables the victim of a ooding attack or the server of a ash crowd to be able to stop individual
Backward Compatibility. Legacy clients and servers do not break SIFF, and legacy clients can communicate with updated servers and vice versa. However, both clients and servers must be updated to take advantage of the systems benets. To construct a system with these properties, we begin with the following assumptions, some of which we use for simplicity of presentation and will relax or remove in Section 5.2. We rst assume that a victim has the ability to determine that it is under attack, and can differentiate between legitimate client ows and malicious or misbehaving ows. We do not require that this differentiation be on a per-packet basis, or that it be lightweight; only that it exist. 1 However, the details of a trafc differentiation algorithm are application specic and orthogonal to the focus of this paper, which simply assumes their existence. Secondly, we assume that clients, servers and routers are redesigned and conform to a modied IP network layer (non-updated clients and servers will still be able to communicate with updated clients and servers, but they will not realize the benets of the new system). Specically: Marking space in the IP header. We assume that the IP header has sufcient space to accommodate the information that routers mark in the packet. Routers mark every packet. We assume that SIFF routers are capable of executing minor manipulations of the marking eld of every packet that they forward. These manipulations can be done in parallel with a routing table lookup. This assumption is minor, since Internet routers must already decrement the TTL and recalculate the IP Header Checksum of every packet they forward. Short-term Route Stability. We assume that Internet routes are stable on the order of the time of a client/server transaction. Violation of this assumption will not break our system outright, rather, the systems performance is likely to decrease with increasing route instability below the time required for a client/server transaction. Network routes are more likely to uctuate under DDoS attack, precisely when our system requires their stability. However, SIFF will also mitigate the effect of DDoS on routers (as packet oods are dropped early in the network), and is, in this way, self-reinforcing. Unfortunately, it is difcult to model the behavior of a system as complex as the Internet, especially under DDoS attack, so verication of this assumption is an open problem.
our mechanism limits source address spoong, it can make malicious host identication easier.
1 Because
Our approach divides all Internet trafc into two types, privileged and unprivileged. Privileged packets are always given priority over non-privileged ones when contending for bandwidth. To establish a privileged channel, a client must obtain a capability through a special handshake over an unprivileged channel. Privileged channels consist of specially marked packets embedded with the capability obtained through the unprivileged handshake. The capabilities in SIFF are based on information inserted into all packets by the network en route to their destinations. This mechanism is similar to that of P i, proposed by us in an earlier paper [47], except that in SIFF, the computation process for markings is slightly more elaborate, as packet markings change over time (as opposed to remaining constant in P i), and are used by both routers and endhosts, rather than just by endhosts. The capability is generated piecemeal by each router and marked in a eld of the packet along the path to the packets destination. The pieces at each router are generated entirely from packet header data and local topology information. SIFF provides the above benets to the receiver of a privileged channel. When forwarding a privileged packet, a router simply checks part of the embedded capability to see if it matches the markings that the router would have added to an unprivileged packetif they match, then the packet is forwarded; if they do not, then the packet is dropped. The capabilities themselves are based on the packet markings, which change independently at each router with a certain frequency. Routers maintain a window of valid markings and signal a change of marking to a packet recipient by replacing old markings in the embedded capability with new ones. Because the packet recipient, rather than the packets sender, is receiving the capability updates, continued privileged communication requires that the receiver periodically update the senders capability. Thus, the receiver of a packet ow has the option to halt that ow by simply refusing to forward capability updates. Attackers can still ood using unprivileged packets, but they will no longer disrupt existing privileged communications. Furthermore, during an unprivileged ooding attack, a legitimate client and server need only pass two packets (a total of one round trip) between themselves to establish a privileged channel and communicate, undisturbed, over privileged packets.
3 Design
The SIFF system provides a server with the ability to establish privileged communication with whatever clients it chooses by providing those clients with a capability token. 2
2 For ease of presentation, we refer to a ows source as the client and a ows destination as the server. This does not mean that privileged channels can only be established from clients to servers.
4
Privileged packets carry capabilities that are veried piecemeal (and statelessly) by the routers in the network, and are dropped when the verication fails. Routers implementing SIFF are programmed to give preferential treatment to privileged packets, so that privileged packets are never dropped in favor of unprivileged ones (legacy packets not conforming to our scheme are treated as unprivileged packets). Privileged channel capabilities are time limited and require updating by the server to remain valid. Because server cooperation is required for capability updates, a server can halt the packets of a privileged channel by simply quenching its capability update messages. At a high level, the system works as follows: clients and servers participate in a handshake (similar to the TCP handshake, which can be carried on top of this handshake) using a specic type of unprivileged packet known as an EXPLORER (or EXP) packet. Routers insert path specic information into EXP packets, whos aggregate among all the routers in the path is used as a capability token for a privileged channel between the client and the server. After the handshake, clients and servers communicate using privileged packets called DATA (or DTA) packets, into which they insert the capabilities carried in the EXP packets. When routers forward a DTA packet, they rst check to see if part of its capability equals that information which would have been inserted into the packet had it been an EXP packet. If the markings match, then the packet is forwarded. If not, then the packet is immediately dropped. Our discussion assumes a new format for the IP header. The following elds are assumed to be present: Flags eld (3-bits). This eld contains the following 1-bit ags: the signalling ag (SF), used to indicate that the packet is a non-legacy (either EXP or DTA) packet; the packet type ag (PT), used to indicate that the packet is either a DTA (set) or EXP (unset) packet; and the capability update (CU) ag, set to indicate that the optional capability reply eld is present in the header. Capability eld. This eld is used by routers to add their marks to the packet en route to its destination. (Optional) Capability reply eld. This eld is used by packet recipients to signal to the packet sender a new (or updated) capability, and is only present when the capability update ag is set. We do not assume an exact length for the capability or capability reply elds, as their lengths will depend upon other parameters (such as the bits marked per router and maximum path length). We assume the presence of a source and destination address in the header, but not their exact length. No other elds of the packet header are used in our scheme. 5
In the following subsections, we describe in detail the handshake protocol, as well as the potential issues in its implementation.
3.1 Handshake Protocol
Any client wishing to contact a server over a privileged channel must rst complete a handshake protocol to obtain a capability to insert into its privileged packets, and vice versa for server communication with the client. A single handshake is sufcient to provide both sides of a communication with their capabilities. Furthermore, handshake packets can carry upper layer protocol data. The protocol is shown in Figure 1.
Figure 1. Handshake establishing a privileged channel. A client sends an EXPLORER packet to the server, which gets marked with marking . The server responds with its own EXPLORER packet, with enclosed in the capability reply eld. The client sends its rst DATA packet with in its capability eld and with , from the servers EXPLORER packet, enclosed in the capability reply eld.
The initiator of the handshake (the client) rst sends out an EXP packet with its Capability eld initialized to 0. A packet is marked as an EXP packet by setting the signalling (SF) ag and leaving the packet type (PT) ag unset. All routers along the path left shift z bits into the Capability eld the EXP packet (see Section 3.2 for a description of how these markings are computed). The exception to this rule is that the rst router in the path that sees a marking eld of all 0 bits inserts a 1 bit before its marking (so that the actual capability in the eld will consist of all bits up to, but not including, the most signicant 1 bit.). Recall from Section 2 that we assume that the marking eld is large enough to accommodate the markings from all of the routers in the path plus the 1 bit inserted by the rst router. EXP packet marking is shown in Figure 2(a).
(a) Marking scheme for EXPLORER packets. Routers push their markings into the least signicant bits of the capability eld. Packets with a capability eld of all zeros get marked with an additional 1 bit.
(b) Authentication scheme for DATA packets. Routers check the marking in the least signicant bits of the capability eld, and rotate it into the most signicant bits, if it is equal to what the marking would be for an EXPLORER packet.
(c) Windowed authentication and marking for DATA packets. Routers check that the marking equals one of the valid markings in its window and always rotate the newest marking in the window into the capability eld.
Figure 2. Marking and authentication schemes for EXPLORER and DATA packets. When the EXP packet arrives at the server, the server creates a response packet. The response packet is also an EXP packet, with the Capability eld initialized to zero, but with the capability update (CU) ag set, and the Capability Reply eld initialized to the contents of the Capability eld of the EXP packet from the client. When the servers EXP packet arrives at the client, the client examines the Capability Reply eld, takes all the bits up to but not including the most signicant 1 bit in the packet, splits them into groups of z bits and reverses the order of the groups to obtain its capability. This capability is inserted into the Capability eld of all subsequent privileged packets that the client sends. To complete the handshake, the client must send the server its capability, marked by the routers in the servers EXP packets Capability eld. The client creates a DTA packet, with the CU ag set and the Capability eld from the servers EXP packet in the Capability Reply eld; just as the server did for the client. The router behavior for marking and forwarding DTA packets is different from that used for EXP packets. When a router receives a DTA packet, it calculates a marking as though the packet were an EXP packet, but then only veries that the marking it has calculated is equal to the marking in the least signicant bits of the Capability eld. If the marking is not equal, then the packet is immediately dropped. If the marking is equal, then the router right shifts that marking into the most signicant bits of 6
the Capability eld. This causes the markings for the next hop router to occupy the least signicant bits. DTA packet marking is shown in Figure 2(b). A DTA packet will only reach its destination if all the routers along its path match their markings to the least signicant bits of the packets Capability eld. Once the clients privileged DTA packet arrives at the server, the server can compute its capability in the same way that the client did and the handshake is complete, as both hosts can now communicate over privileged DTA packets.
3.2 Router Marking Calculation
As described in the previous section, each router must calculate a marking for every packet that it forwards; it leftshifts the marking into the packet in the case of an EXP packet, or veries and right-shifts the marking in the case of a DTA packet. For a particular packet, the marking is calculated as the last z bits of the output of a keyed hash function with the following parameters as input: the IP address of the interface at which the packet arrived at the current router, the last-hop routers outgoing interface IP address 3 , and the source and destination IP addresses of the packet being forwarded. The use of the source IP address as a hash input has the effect of tying a capability to a particular host and eliminates the effect of source address spoong. If the attacker is on a shared medium network with a legitimate client and observes a capability transmitted to that client, the attacker is limited to spoong the clients IP address when ooding using that clients capability. The server will revoke the capability (using a mechanism we introduce in Section 3.2.1) and all packets using the clients capability will be dropped from the network. Although this results in a DoS on the client, the attacker can presumably accomplish the same goal by simply ignoring the transmission control mechanism of the shared medium it occupies. The use of the destination IP address as a hash input prevents attackers from generating marking maps by sending EXP packets from one attacker to another and observing the marks that result. Any marks learned in this fashion will be invalid when used to ood DTA packets to a different machine. 4 For SIFF to effectively stop forged privileged packet oods, a router must be able to calculate its marking faster than it can perform a route lookup. Otherwise, attackers could simply ood a router with illegitimate DTA packets,
3 The last-hop routers IP address is used to improve the entropy of the marking [47]. 4 A more serious vulnerability for a server would be to have a colluding or unwitting host on its network respond to EXP packets, thus providing an attacker with a capability that can be used to ood privileged DTA packets to the servers network. However, this problem can be avoided by careful administration of the victims network.
causing the router to either overload its route-lookup capability or ll its buffer with DTA packets, and start dropping potentially legitimate DTA packets indiscriminately. To meet this performance goal, the router must be able to calculate the hash function in hardware. Alternatively, the router could select a random subset of bits of the source and destination IP addresses to use in its hash function (it is assumed that IPi1 and IPi change infrequently), and precalculate the hash results using all possible permutations of these input bits. Of course, the bits of the addresses used for the hash calculation would have to change periodically to avoid attackers identication of them, perhaps as part of the mechanism described in Section 3.2.1. EXPor legacypacket oods do not interfere with DTA packets, because of the priority given to DTA trafc. However, even under these oods of packets the overall performance of the router need not suffer, because the marking calculation (or precalculated marking lookup table) can be executed in parallel with the routing lookup in the router because the marking does not depend on any routing decisions. 3.2.1 Key Switching Thus far, the router information inserted into packets has been treated as static and unchanging. If this were the case, than an attacker could simply obtain a capability through a seemingly legitimate request, and then use that capability to ood the server with privileged trafc. To meet the design goal of allowing a server to stop a malicious ow that is already in progress, we introduce the router key switching mechanism. To prevent an attacker from abusing a legitimately acquired capability, we require that the capabilities in our system change over time. This is accomplished by having the routers change their markings periodically, by changing the keys to the hash functions they use to compute the markings. However, rather than invalidate an entire capability and force the client and server to execute another handshake simply because one router changes its key, keep routers a window of x keys as valid at any one time, where x > 1. When a privileged packet with an old marking (i.e. one still present in the routers window, but not the most recently computed one) arrives at the router, the router shifts the most recent marking into the packet, thus providing the server with an updated capability. The server can then signal its client of the updated capability using the CU and Capability Reply mechanism, if the client is well-behaved. 5 Figure 2(c) shows window verication and
5 A server in our scheme can be implemented with or without state. A stateless receiver does not need to keep track of the capability for each client and would simply reply to any packet by setting the CU ag and lling in the Capability Reply eld with the value in the latest privileged packets Capability eld from that client. If the client is deemed
7
marking of privileged packets.
4 Analysis
4.1 Privileged Packet Flooding
SIFF mitigates the impact of ooding (or bandwidth starvation) DoS attacks by isolating and protecting established privileged communication from unprivileged communication and enabling the receiver to downgrade privilege. In this section, we analyze the robustness of our scheme against oods of privileged packets with forged capabilities. First, we derive the probability that an unauthorized router or end-host will be able to forge (by guessing) the appropriate capability to allow its packets to reach a potential victim. Recall from Section 3 the two parameters: x, the number of markings each router maintains in its window; and z, the number of bits per router marking. The probability that a randomly guessed capability will pass a particular router is given by: P (x, z) = 1 1 1 2z
x
off. As we show in Section 3.2.1, x must be at least 2, otherwise every key change would force an additional handshake between the client and server. Because a valid capability is one that matches any of the x capabilities in the routers window, small values of x provide the smallest probability that a randomly chosen capability will pass through a router. (Table 1 shows this effect). The value of x also affects the validity time of a capability. The minimum validity time (minm ) is minm = (x 1) TK , where TK denotes the time a key (marking) is active (valid). The maximum validity time (maxm ) is maxm = x TK . Ideally, we would like to get a small interval for the validity time, so that we can tightly control the validity period, so we would like large values of x to minimize the difference between minm and maxm . We can determine x from minm and maxm : maxm x= maxm minm Because capabilities are only updated when the client and server send packets to each other, the minm metric should be set just low enough so that all handshakes and most packet trafc should be able to go back and forth from client to server within that time period. The maxm metric denes the longest amount of time that a connection can remain idle and still have a valid capability. Put in another way, maxm denes the maximum amount of time that an attacker can ood privileged packets with a particular capability, before that capability is rejected by the network. We leave the exact timing decisions to the community, and simply assume in our experiments that x is likely to be from two to ve.
20000 champagne monitor (Urbana, IL) f-root montior (Palo Altol, CA) m-root monitor (Tokyo, Japan) 15000
z=1 z=2 z=3 z=4
x=2 0.7500 0.4375 0.2344 0.1211
x=3 0.8750 0.5781 0.3301 0.1760
x=4 0.9375 0.6836 0.4138 0.2275
x=5 0.9688 0.7627 0.4871 0.2758
Number of Paths
and the probability that a randomly guessed capability will pass all d routers in a path is simply P (x, z)d . Recall from Section 3 that the capability eld must be large enough to accommodate the markings of all routers in the path (plus an additional 1 bit to indicate the rst marking in the eld), or else the markings of some routers will be pushed out of the eld, and the capability (when used by the sender of that packet) will not pass the inspection of those routers whose markings were dropped. Table 1 shows P (x, z), the probability of successfully forging a capability to pass a single router, for reasonable values of x and z.
10000
5000
Table 1. Evaluation of P (x, z) (the probability to pass one router with a forged probability), for common values of x and z.
0
10
20
30
Path Lengths
Figure 3. Path length distribution for three CAIDA skitter monitors. Choosing a value for x (the maximum number of keys that are valid at any one time on a router) presents a trademalicious, the automatic reply can be stopped. Although always responding with a capability update wastes bandwidth, we present this mechanism for those concerned with maintaining IP as stateless at the endhosts. A stateful implementation of this system is straightforward, and preferred.
In Figure 3 we show the plots of the path lengths of the Internet maps generated at three different CAIDA skitter monitors [9]. To analyze the performance of our scheme in ltering oods of forged privileged packets, we select 8
1 No Filtering Filtering (z=1, x=2) Filtering (z=2, x=2) Filtering (z=3, x=2) Filtering (z=4, x=2) Ideal Filtering
1 No Filtering Filtering (z=2, x=5) Filtering (z=2, x=4) Filtering (z=2, x=3) Filtering (z=2, x=2) Ideal Filtering
Ratio of Total Attack Packets
0.8
Ratio of Total Attack Packets
0.8
0.6
0.6
0.4
0.4
0.2
0.2
0
0
10
20
30
0
0
10
20
30
40
Hops from Victim
(a) Performance for various values of z, (x = 2).
Hops from Victim
(b) Performance for various values of x, (z = 3).
Figure 4. Packet ltering performance for varying bits per router (z) and window sizes (x). attackers at random from our map, and have them send a number of packets with randomly forged capabilities. The number of attackers and the number of packets per attacker do not affect the outcome of our experiment, in which we simply drop a certain percentage of attack packets at each hop. We show the results of our experiments only from the f-root skitter monitor; which are the most pessimistic because of the high concentration of paths close to the victim relative to the other two monitors path distributions. Figure 4(a) shows the ratio of total attack trafc at each hop from the victim for varying values of z. As expected, without ltering of any kind, eventually all attack packets arrive at the victim. Furthermore, with ideal ltering (routers automatically drop all attack packets) we see a curve that matches the path distribution, since the attackers packets are immediately dropped after one hop. The SIFF scheme performs excellently, ltering out 97.14% of the attack trafc using only a one bit marking per router (z=1), and ltering out 100% of the attack trafc (six nines) with a marking scheme of four bits per router (z=4). Figure 4(b) shows the same experiment with a constant z and a varying x. As expected (and suggested by Table 1) the effect on ltering performance caused by varying z is far greater than that caused by varying x. Furthermore, although not shown in the gure, it is intuitive that the effect of varying x decreases as z increases. few of the forged packets reach destinations even close to the victims network. In this section, we analyze a different attack approach, which is to ood with unprivileged packets for an extended period of time with the goal of stopping all new connection establishments. However, unlike the current Internet infrastructure, in which established TCP ows can still be affected by IP packet oods, SIFFs privileged ows are unaffected by unprivileged trafc congestion. Thus, a client and server only need to exchange two packets within minm time, the least amount of time that a capability is valid (dened in the previous section), before the privileged channel between them is established and they can communicate from then on, unaffected by the ongoing attack. We assume that unprivileged trafc is causing congestion at the last i hops of the network, and that the probability of getting dropped at any one of those routers is i . We ignore the probability of the server getting its outbound packets dropped, because congestion in the routers during ooding attacks is typically experienced by inbound packets only. Because the drop probabilities at routers are independent Bernoulli trials, the probability that a client and server will be able to establish a privileged channel after one try (by exchanging two packets is): P (connect after 1 try) = (1 i )i . The probability that the client can connect after k tries is: P ( connect after k tries) = 1 (1 P (connect after 1 try))k = 1 (1 (1 i )i )k For a given desired connection probability, P (connect) 9
4.2 Privileged Channel Establishment Under Unprivileged Packet Flooding
As shown in the previous section, attacker ooding of privileged packets has little effect on the victim, because so
the required number of connection attempts is: k= log(1 P (connect)) log(1 (1 i )i )
A nice feature of this formula is that the expected number of connection attempts depends logarithmically on the connection probability, which indicates that even for large i , a determined client can get a connection after a moderate waiting time.
5 Discussion
In this section, we discuss some limitations, practical issues and extensions to SIFF. We rst discuss several classes of bandwidth starvation attacks against which SIFF does not completely defend. We also discuss a high-level approach for implementing SIFF in an IPv4 environment, the combination of SIFF with puzzle auctions, the possibility of multiple capabilities with different validity lengths, and the effect of route stability on our scheme.
privileged trafc, causing other privileged trafc traversing that network to experience congested links. A possible solution to this attack would be to have routers rate-limit individual capabilities, similar to the Aggregate Congestion Control/Pushback mechanism [27]. It is also important to note that, as designed in this paper, SIFF is a layer-3 (IP) mechanism. As such, SIFF can grant capabilities only at the granularity of hosts (i.e., single IP addresses). For example, a SSH server cannot give privilege to an SSH client without also granting privilege to any other connection from that host.
5.2 Deployment in the Current Internet
The limited space in the IPv4 packet header and the limited deployment that any routing infrastructure change is likely to achieve makes it necessary to redesign SIFF. Fortunately, both of these constraints can be satised by a single approach: rather than constructing a system where forged privileged ows are dropped anywhere in the network we focus on hardening individual ISPs against such trafc ows. We assume two possible deployment models: full ISP deployment and border ISP deployment. In the full ISP deployment model, all routers under the control of a particular ISP are upgraded with our scheme, whereas border ISP deployment requires only that all of an ISPs border routers be upgraded. The intuition behind both approaches is that by limiting the number of marking routers (to just the routers of the packets destination), each router can mark more bits in the available marking space and forged privileged ows can still be stopped, albeit only once they arrive at the victims ISPs domain. Note that end-hosts, both clients and servers, will still need to be modied to take advantage of these schemes. SIFF requires some available space for marking in the IPv4 packet header. We require one bit of the IP header that is currently reserved (set to zero by all end-hosts) to act as the signalling ag (SF) which, as mentioned in Section 3, will differentiate legacy trafc from all trafc used in our scheme. We do not assume any particular location for the remaining markings, although of course, any location chosen should avoid interaction with legacy protocols (we offer some insight into how to avoid interaction with fragmentation when marking the IP Identication eld in Appendix A). Furthermore, we remove the capability update (CU) ag and assume that half of our available marking space is used for capability replies in every packet. The packet type (PT) ag remains unchanged. Thus, if we assume x bits available in the IPv4 packet, then x2 bits are 2 used for capability marking, x2 bits are used for capability 2 replies, and 2 bits are used for ags. We show SIFFs performance for varying numbers of marking bits in Figure 5. The gure shows a signicant reduction in the percent of 10
5.1 Limitations
We have identied several types of bandwidth attacks that SIFF does not defend well against. We briey describe them in this section. Although SIFF binds a source IP address to a particular capability (thus limiting the possibility of spoong in privileged ows to the same as ubiquitous ingress ltering), without a mechanism to identify malicious trafc, it is still possible for an attacker to rotate the active machines in its attack. Presumably, when a subset of attacking machines are blacklisted the attacker would activate a different subset to request (and abuse) new capabilities. However, depending on the size of the victims blacklist, the attacker will be limited in the number of active machines used at any one time in the attack. In a topology where not all routers implement SIFF, it may be possible for a carefully placed bandwidth attack to disrupt privileged communication. If the attacker pinpoints a link where a router does not implement SIFF, then by ooding that link with unprivileged trafc he can cause privileged trafc to be dropped, because the router at that link will not give priority to privileged trafc. To prevent this attack, it is sufcient that the router on the attacked link implement the preferential treatment of privileged packets, rather than the whole SIFF protocol. The case of colluding attackers is difcult to solve in SIFF. As mentioned in Section 3.2, a colluding attacker node on or near the victims network can return capabilities to attacking nodes outside the network. In general, colluding attackers on either side of a transit network may simply grant each other capabilities and ood the network with
total attack trafc arriving at the victim, ranging from 25% to 98.7%, depending on the number of marking bits used. Finally, we address a security hole in the border ISP deployment method. An attacker could determine its capability by simply sending a packet designed to produce an ICMP error message at a router between the victim and the ISPs border routers (for example, a TTL expiration). The ICMP error packet sent by the router will include in its payload the IP header and the rst 8 bytes of the payload of the original packet, thus returning to the attacker the capability that will bypass the ISPs border routers. An approach to prevent this attack is to have all the border routers of the ISPs network monitor outbound ICMP error messages and remove the contents of the marking eld in messages that contain EXP packets. Although this may degrade performance on border routers, ICMP has a simple header, so packet inspection can be implemented in hardware. ICMP attacks are not a problem for full-ISP deployment because capability enabled routers can be programmed to mask out the marking eld of all EXP packets before they are encapsulated in ICMP error packets. Border ISP deployment is also subject to the legacy router bandwidth attack described in Section 5.1.
1 0.9
to the high frequency of their capability requests) to devote as many resources to solving a puzzle as a legitimate client. In a combined scheme, a client would transmit a value x in its initial EXP packet representing the difculty of the puzzle it wishes to solve. The server will receive the capability y of l bits in length and respond with yl(x+1) |h(y)x0 (where h(y)x0 is the least signicant x bits of the hash of the capability y, and | is concatenation). The client must perform 2x1 hash operations, on average, before nding the correct pre-image of the last x bits of the capability. This scheme could be used without adding any elds beyond those already assumed in Section 3. Puzzle auctions, in this context, have the disadvantage that they reduce the search space for an attacker trying to forge valid capabilities. Furthermore, there is a limit to the difculty of the puzzle given to the client, because the capability contained within the puzzle may expire while the client is solving it.
5.4 Path Stability Effects
In Section 2 we assume Internet route stability (on the order of a client transaction). If a route changes mid-ow, then a clients privileged packets will be dropped by the new routers in the path (with high probability), and it will force the client to renegotiate the SIFF handshake before being able to send further privileged packets. Route instability can be caused by multiple path effects. Teixeira et al. analyze the CAIDA skitter topologies to show that at least half of the endpoints in the Internet have more than 2 partially-disjoint paths (where there are no common routers between the source and destination ASes) [44]. However, this result is orthogonal to our systems performance as long as routing decisions between multiple equalcost paths are implemented in a ow preserving way (eg. by hashing the ow elds of the TCP/IP packet headers) as suggested by RFC2992 [20]. Furthermore, large-scale route apping has been shown to be detrimental to TCP performance due to the difculty in estimating path characteristics such as round trip time [33]. Localized load-balancing does not hurt TCP performance, but we assume that local load balancing nodes can be manually congured to produce the same markings. An alternative SIFF forwarding policy may mitigate the effect of mid-ow route changes. Rather than dropping a privileged packet whose capability fails the verication test, a router can simply demote the privileged packet to unprivileged status. Furthermore, if unprivileged packets were marked in the same way as privileged packets (with markings pushed into the MSB of the capability eld) then this mechanism would allow the demoted packet to carry the updated capability to the server in the same way that a privileged packet would. Using this scheme, route changes 11
Ratio of Total Attack Packets
0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0 1 2 3 4 Bits, Border Deployment 8 Bits, Full Deployment 8 Bits, Border Deployment 16 Bits, Full Deployment 16 Bits, Border Deployment 4 5
Hops from Victim
Figure 5. Percentage of attack packets in the last 5 hops to the victim for different marking sizes and deployment methods.
5.3 Puzzle Auctions
SIFF can be combined with Wang and Reiters puzzle auctions [46], to minimize the assumption that a server needs to differentiate between legitimate and malicious clients. The intuition behind puzzle auctions is that a client makes a bid as to the difculty of the puzzle it is willing to solve in order to receive a capability. Presumably, compromised machines are unwilling (due to the chance that their users would discover the compromise) or unable (due
would only effect privileged connectivity when the server i...