A Lightweight Opportunistic Tunneling 1 - Semantic Scholar

A Lightweight Opportunistic Tunneling 1 Yossi Gilad and Amir Herzberg Network Security Group, Computer Science Department, Bar Ilan University. Technical Report 11-02 (October 2011).

We present LOT, a lightweight ‘plug and play’ secure tunneling protocol deployed at network gateways. Two communicating gateways, A and B, running LOT would automatically detect each other and establish an efficient tunnel, securing communication between them. LOT tunnels allow A to discard spoofed packets that specify source addresses in B’s network and vice-versa. This helps to mitigate many attacks, including DNS poisoning, network scans and most notably (Distributed) Denial of Service (DoS). LOT tunnels provide several additional defenses against DoS attacks. Specifically, since packets received from LOT-protected networks cannot be spoofed, LOT gateways implement quotas, identifying and blocking packet floods from specific networks. Furthermore, a receiving LOT gateway (e.g., B) can send the quota assigned to each tunnel to the peer gateway (A), who can then enforce near-source quotas, reducing waste and congestion by filtering excessive traffic before it leaves the source network. Similarly, LOT tunnels facilitate near-source filtering, where the sending gateway discards packets based on filtering rules defined by the destination gateway. LOT gateways also implement an inter-gateway congestion detection mechanism, allowing sending gateways to detect when their packets get dropped before reaching the destination gateway and to perform appropriate near-source filtering to block the congesting traffic; this helps against DoS attacks on the backbone connecting the two gateways. LOT is practical: it is easy to manage (‘plug and play’, requires no coordination between gateways), deployed incrementally at edge gateways (not at hosts and core routers), and has negligible overhead in terms of bandwidth and processing, as we validate experimentally. LOT storage requirements are also modest. Categories and Subject Descriptors: C.2.2 [Computer-Communication Networks]: Network Protocols General Terms: Security Additional Key Words and Phrases: IP Spoofing, Denial of Service ACM Reference Format: ACM Trans. Info. Syst. Sec. V, N, Article A (January YYYY), 33 pages. DOI = 10.1145/0000000.0000000 http://doi.acm.org/10.1145/0000000.0000000

1. INTRODUCTION

Most packets sent on the Internet are not authenticated; namely, attackers are often able to send spoofed packets, containing incorrect sender IP address. The IETF recommends that Internet Service Providers (ISPs) will block packets from their customers that specify source IP address not assigned to the sender, i.e., ingress filtering [Killalea 2000; Ferguson and Senie 2000; Baker and Savola 2004]. Indeed, [Advanced Network Architecture Group 2011] found that most surveyed clients were unable to send spoofed packets. However, there are still many ISPs that do not perform ingress fil1A

preliminary version of this paper appeared in ESORICS 2009 [Gilad and Herzberg 2009].

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or [email protected]. c YYYY ACM 1094-9224/YYYY/01-ARTA $10.00

DOI 10.1145/0000000.0000000 http://doi.acm.org/10.1145/0000000.0000000 ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:2

Y. Gilad and A. Herzberg

tering, especially in less developed countries; which, although highly populated, were under-represented among the volunteer-participants in [Advanced Network Architecture Group 2011]. In particular, [Pang et al. 2004; Beverly and Bauer 2005] found that IP spoofing and lack of ingress filtering are quite common. IP spoofing is exploited in many attacks, including network scans [Peng et al. 2007], DNS poisoning [Klein 2007; Kaminsky 2008], and other attacks, e.g., on SNMP [Jiang 2002; Aharoni and Hidalgo 2005]. In most of these attacks IP spoofing is essential, since the attacker is required to impersonate a specific entity (e.g., the authoritative DNS server for DNS poisoning). Finally, IP spoofing is often exploited to cause clogging, the generation of excessive amounts of network traffic, resulting in severe congestion and disruption of Internet communication, i.e., a (network-layer) Denial of Service (DoS) attack. Clogging and other forms of DoS attacks are widespread [Moore et al. 2001] and facilitated by a huge number of hosts in the Internet (often in botnets), as well as by the widespread ability to send spoofed packets. In particular, the following clogging-DoS attacks exploit spoofing: IP flooding [Chang 2002], SYN-flooding/clogging [Harris and Hunt 1999; Lemon 2002; Eddy 2007] and (DNS and other) reflection attacks [Paxson 2001]. One reason that spoofing is often facilitated in these (and other DoS) attacks is that it allows evasion of filters and quotas based on sender IP address, makes tracing attacks harder, and allows reflection DoS attacks [Paxson 2001]. In reflection DoS attacks [Paxson 2001], each attacking bot B1 , B2 , . . . , Bn sends (short/single) requests to one or many reflecting hosts R1 , R2 , . . . , Rm . The requests are spoofed: their source address is of the victim V , instead of their real addresses. Hence, the reflecting hosts send the (longer/multiple) response(s) to the victim, flooding it or links to it with excessive traffic. DoS reflection attacks can significantly amplify the abilities of the attacker, allowing a weak spoofer or a small number of spoofers to disrupt services. We present LOT, a Lightweight Opportunistic Tunneling protocol, deployed on network gateways. LOT is designed to mitigate the two critical, widely exploited attack vectors, IP spoofing and clogging. Once installed on a gateway, say GWA , LOT begins probing remote connections to find peer LOT gateways; when a peer gateway, GWB , is found, LOT establishes a tunnel between GWA and GWB . Once a tunnel is established, GWA adds a pseudo random tag to packets sent to GWB who discards packets without the tag if their source address is in the network block of GWA (and vice-versa). This method resembles packet marking techniques such as [Savage et al. 2000; Snoeren 2001; Dean et al. 2002], but does not require deployment at ISPs and on Internet routers. The basic deployment topology for LOT is illustrated in Figure 1, where a tunnel is established between GWA and GWB , two gateways of communicating hosts Alice and Bob; the tunnel protects GWA and GWB ’s networks from Eve, an outside attacker (e.g., on the Internet). LOT is opportunistic: it requires no coordination between the administrators of the two gateways; instead, once it is installed on both gateways, LOT automatically sets up a lightweight security tunnel between them. By blocking spoofed packets LOT defends against many (DoS and other) attacks; Figure 2 compares two clogging DoS attacks by a spoofing adversary, Eve: a simple flood attack and a DNS reflection attack (amplification ratio is 10). Both attacks are on the client, Bob, using the network topology in Figure 1. We compared data transfer time (over a TCP connection) and packet loss rates for different attacker bandwidths; Figure 2 describes the attacker bandwidth as percentage of link bandwidth allocated to all other links (100Mb/s). As expected, the reflection attack causes a more severe degradation in performance compared to the direct attack. Figure 2 also shows how LOT mitigates the reflection attack.

ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

Lightweight Opportunistic Tunneling

A:3

Router Alice

Bob

GWB

GWA Authoritative DNS server Eve

Fig. 1. LOT is deployed on GWA and GWB and forms a tunnel between them.

0.7

DNS reflection Reflection attack, LOT deployed Direct attack

25 20 15 10 5

DNS reflection Reflection attack, LOT deployed Direct attack

0.6 Packet loss ratio

Data transfer time in seconds

30

0.5 0.4 0.3 0.2 0.1 0

0 0

0.05 0.1 0.15 0.2 Attacker’s bandwidth as a portion of link bandwidth

(a) DNS reflection attack effect on a connection.

0

0.05 0.1 0.15 0.2 Attacker’s bandwidth as portion of link bandwidth

(b) DNS reflection attack effect on packet loss ratio.

Fig. 2. Comparison between DNS reflection attack and flooding attack, with and without LOT. DNS requests are 55 bytes and responses are 550 bytes (amplification ratio of 10). The graphs provide the confidence interval at a level of 95% for each measurement.

Furthermore, LOT facilitates several additional defenses against Denial of Service (DoS) attacks: Local and Remote Quotas. Since LOT prevents spoofing, ‘receiving end’ gateways can now enforce quotas on traffic without the risk of blocking traffic from a legitimate source, s, due to excessive spoofed traffic, falsely identified as coming from s. The gateway can enforce an additional quota for all destinations in network blocks with whom the gateway does not have a tunnel. Furthermore, LOT allows a receiving end gateway, GWB , to send the sender’s gateway, GWA , the quota it allocates for GWA ’s network, allowing GWA to block excessive traffic before it leaves the source network. Near-Source Filtering. Receiver’s gateway, GWB , can request the sender’s gateway, GWA , to block (filter) certain types of packets, permanently or temporarily. This can be useful to block network scans and other attacks that can be filtered easily (e.g., DNS responses sent to a web server, usually due to DNS reflection attack). The filtering rule can be defined manually or automatically, by appropriate learning mechanisms and intrusion detection systems. Inter-Gateway Congestion Detection. LOT gateways periodically measure the portion of packets that they sent and were also received at the remote end of a particular tunnel. A significant number of packets sent, but not received is an indication of multiple packet losses, typically due to congestion. The sending gateways can react, e.g., drop packets from suspect senders (behind them); this can help mitigate DoS attacks against core Internet routers, such as the Coremelt attack [Studer and Perrig 2009] (see our simulations in Section 6) or the opt-ack attack [Sherwood et al. 2005]. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:4


Many of LOT’s benefits are significant only when it is deployed in a considerable portion of Internet gateways. However, LOT provides incentives even for early deployers, see Section 2.2. The tunneling mechanism is lightweight and optimized for efficiency much like GRE [Farinacci et al. 2000; Dommety 2000]. However, LOT provides a unique value by establishing ‘transparent’ tunnels. Namely, LOT does not modify the source and destination addresses; this allows packets within a LOT tunnel to flow in arbitrary routes to the destination, rather than forcing them to flow via a specific gateway, as when using most existing tunneling mechanisms (which change the destination, typically to a particular network gateway, for decapsulation). LOT sets up hop by hop tunnels on a route between communicating hosts, this allows filtering of spoofed or clogging traffic near the source (i.e., at the nearest LOT supporting node on the route). However, opportunistic hop by hop design implies that a MitM attacker can impersonate a legitimate ‘next hop’ gateway. Furthermore, since LOT is designed to be lightweight, it does not use cryptography for encapsulating or decapsulating packets. For these two reasons LOT is vulnerable to MitM attackers. Paper Organization

The remainder of this paper is organized as follows: Section 2 presents an overview of LOT; we discuss our design guidelines, deployment and prototype implementation. In Section 3 we define the communication and adversary models that we consider in this paper and present our security requirements from LOT. The following two sections present the LOT handshake: in Section 4 we present how potential tunnel endpoints (i.e., LOT gateways) opportunistically discover each other; and in Section 5, we provide a protocol to validate that a network block is behind a gateway and discuss how the output of a successful run can be used to tag traffic; we also provide a security and time analysis. In Section 6 we present mechanisms that, given tagged traffic flows, mitigate denial of service attacks. Section 7 presents LOT’s tunneling mechanism and includes empirical measurements of performance. Section 8 analyzes LOT security, it sketches the proofs for our security requirements. In Section 9 we discuss related works and Section 10 presents our conclusions and directions for future work. 2. OVERVIEW

In this section we present an informal discussion of our design guidelines for LOT, discuss LOT deployment and present our prototype implementation. 2.1. Design Guidelines Do No Harm. LOT tunnels are designed to improve security, in particular protection against IP-spoofing and DoS attacks. These goals are obviously important; however, it is critical that such improvements will not result in significant degradation of efficiency or reliability. Therefore, we require LOT to be a lightweight protocol. In particular, LOT tunnels should be established and operated with minimal overhead, including no or minimal impact on routing. Furthermore, LOT mechanisms should be designed carefully, to make sure that LOT itself cannot be abused to perform DoS, spoofing or other attacks. Incremental Deployment. Deploying new mechanisms for Internet security can be challenging. In light of this, it is highly desirable for such new mechanisms to be incremental; i.e., provide value even when adoption is very limited in order to provide incentives for early adopters. The benefits should gradually increase as the number of deployments grows. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.


A:5

Simple, Easy, Plug and Play. Secure tunneling mechanisms, and in particular IPsec [Kent and Seo 2005; Kaufman 2005; Hoffman 2005], have established a reputation of being overly complex to implement and difficult to deploy. These problems may be the biggest obstacle preventing the wide-spread deployment of IPsec. It is therefore desirable for LOT to return to the ‘KISS principle’: Keep It Simple (Stupid). LOT should not depend on configuring or extending external mechanisms such as DNS, and certainly avoid configuring of mechanisms such as BGP or the reverse DNS tree. These were suggested in previous proposals for opportunistic, ‘plug and play’, tunnels (e.g., [Richardson and Redelmeier 2005]), but are often not controlled by managers of small to mid-sized networks. Scalable. LOT should be scalable to allow for potential large-scale deployment on the

Internet. 2.2. Deployment

There are two typical deployment scenarios for LOT: network to network and network to provider. In the network to network scenario, illustrated as tunnel B in Figure 3, a LOT tunnel is established (opportunistically) between the edge gateway GWC of Bob’s network and the gateway GWB of Alice’s ISP. This ensures that when Bob receives a packet that specifies any host behind the ISP as its source, it was really sent by such a host. The other typical scenario is network to provider, as illustrated by tunnel A in Figure 3. Here, a customer runs LOT at the gateway connecting it to the ISP (GWA ), and establishes (automatically) a LOT tunnel - tunnel A, to another LOT gateway (GWB ), installed by the ISP. This deployment can help ISPs with complex networks enforce ingress filtering; note that ISPs often experience problems enforcing ‘classical’ ingress filtering on complex networks, see [Baker and Savola 2004]. Multiple tunnels may be established on the route between two networks as illustrated in Figure 3. Tunnel A

Tunnel B

ISP Alice

GWA

GWB

Internet

GWC

Bob

Eve

Fig. 3. Two LOT tunnels: from customer to ISP (Tunnel A), and from ISP to remote network (Tunnel B).

A network may be connected to the Internet or other networks via multiple gateways. LOT supports this (common) scenario, illustrated in Figure 4. Specifically, as opposed to tunneling protocols such as IPsec [Kent and Seo 2005; Kaufman 2005; Hoffman 2005] or GRE [Farinacci et al. 2000; Dommety 2000], LOT avoids impact on routing efficiency. This is accomplished by encapsulating packets without changing their source or destination address to that of a particular gateway (see discussion in Subsection 7.2); LOT’s ‘transparent’ tunnel provides better performance. 2.2.1. Early Adopters. LOT, like any other tunneling mechanism, requires both ends deploy in order to provide value. We present two scenarios where LOT provides value even for early adopters. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:6

Y. Gilad and A. Herzberg Alice

GWA(1)

Tunnel

GWB

Bob

Internet

NetA

GWA(2)

Fig. 4. LOT deployment when a network is connected via multiple parallel gateways.

The first scenario is a large organization, with multiple branches connected over the Internet. The use of LOT prevents attackers (on the Internet, or inside a specific branch) from impersonating one branch in front of another. Furthermore, LOT provides increased protection against clogging and DoS attacks. Namely, LOT isolates the source network of a DoS attack such that an attack against one branch, that originates from another branch or the Internet, does not cripple its communication with other (LOT deploying) branches. Moreover, LOT does not require its deployment be immediate or synchronized between branches; this eases deployment even in a single organization. Later, clients and peer networks communicating with such organizations will also gain value when deploying, as their traffic will less likely be hindered by DoS attacks. The second scenario is a server that has many clients, e.g., a top-level DNS server. LOT allows such a server to offer improved protection for clients (that deploy LOT) at negligible costs; in particular, LOT allows the server to avoid from keeping per-client state by using a stateless one-way tunnel. The stateless one way tunnel option allows the server to verify encapsulated packets and filter spoofed/congesting traffic without keeping information on the client or its network (details in Section 7.2). This allows servers to establish tunnels with a vast number of clients, without risk of resource exhaustion. Furthermore, such tunnels allow servers to give higher priorities to tagged (LOT) traffic, especially when there is high load. This foils DoS attacks on the server, and provides additional motivation for clients to deploy LOT. 2.2.2. Limitations. We require that all a set of gateways which ‘controls’ all routes to a network block (e.g., GWA(1) and GWA(2) in Figure 4) deploys LOT and cooperates (specifically, shares a secret key). Additionally, each gateway must be configured with the network block associated with each of its physical interfaces. LOT tunnels can not ‘pass over’ Network Address Translators (NATs) [Srisuresh and Egevang 2001]; since network blocks behind such devices are internal, corresponding addresses will not be specified on packets an external LOT gateway receives and will therefore appear as spoofed. Thus, an external gateway cannot form a direct tunnel with a gateway that is behind a NAT. However, NAT devices do not prevent the use of LOT: if LOT is deployed on the NAT as well, then tunnels will be formed to and from the NAT device. 2.3. Implementation

We prototyped LOT for Linux based network gateways and used the prototype to evaluate LOT’s performance and security benefits. Throughout this paper we present results of empirical measurements on our implementation to confirm that deploying LOT is beneficial. Our prototype is available at http://lighttunneling.sourceforge.net. 3. MODEL AND SECURITY PROPERTIES

In this section we present our communication model, adversary model and security requirements. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.


A:7

3.1. Communication Model

An address space S of length l is {0, 1}l (for example, IPv4 [Postel 1981b] has the address space {0, 1}32 ). Each d ∈ S is an address. A set B ⊆ S is a network block in 0 the address space S of length l, if there exists a prefix P ∈ {0, 1}l , l0 ≤ l, such that for every d ∈ S it holds that d ∈ B if and only if d has a prefix P . This is similar to the CIDR notation. Network entities are either hosts, or LOT gateways that run LOT. In the following sections of the paper, we often abbreviate and refer to LOT gateways simply by ‘gateways’. Each entity e is associated with a single network block NB(e) ⊆ S 2 : a host h is mapped to a network block of a single address, i.e., |NB(h)| = 1, a LOT gateway may be associated with a larger network block; see illustration in Figure 5. We often abbreviate the writing and use the host when referring to his address. Two entities e1 , e2 are peers if one of the following holds: — NB(e1 ) ⊂ NB(e2 ) and there is no LOT gateway G such that NB(e1 ) ⊂ NB(G) ⊂ NB(e2 ) (e.g., LOT gateways A, B in Figure 5 are peers). — NB(e2 ) 6⊂ NB(e1 ), NB(e1 ) 6⊂ NB(e2 ) and there is no LOT gateway G such that either NB(e1 ) ⊂ NB(G) or NB(e2 ) ⊂ NB(G), but not both (e.g., LOT gateways B, E in Figure 5 are peers). Network entities can send and receive messages, each message specifies data together with source and destination addresses: src, dst. When a message is sent from an entity e to a destination address dst, it reaches one of the peer e.next(dst) entities, which are determined according to the first non empty set of the following: (1) LOT gateways associated with the smallest network block that contains, but does not equal, NB(e). (2) Entities associated with the largest non-empty network block that contains dst, but not NB(e). In Figure 5 the arrows mark for an entity x all the entities in the set x.next(d). We assume bounds 0 ≤ < 1, δ on the loss and delay on network channels: a message sent from entity e1 to address dst reaches a peer e2 ∈ e1 .next(dst) with probability of at least 1 − > 0; and given that the message reached e2 , the delay until the message was received is at most δ. Let hops(e1 , e2 ) denote the number of hops between two entities e1 , e2 , which is the number of subsequent x.next(e2 ) operations required until a set that contains e2 is returned. Where initially, x = e1 and in following calls x is an element in the set returned by the previous call. For example, in Figure 5, hops(s, d) = 4. LOT gateways are also able to perform LOT-broadcast(m). When a gateway G

Net2

s

Net1

z

A

B C

E

d Net3

D Net4 F

Fig. 5. A modeled topology. s, z, d are hosts in Net1 and Net3 . A − F are gateways, each of them is associated with a network block according to its location. Arrows from entity x mark the corresponding x.next(d) entities.

2 In

reality, a host/gateway can be associated with multiple network blocks, e.g., a gateway connecting multiple networks to the Internet. However, in our model, we treat this scenario as multiple machines associated with single network blocks.


A:8


performs this operation, then m reaches ˜ such that NB(G) = NB(G) ˜ (e.g., in Figure 5, B can send a broadcast any gateway G message that would reach C, D). Broadcast messages are encrypted and authenticated, e.g., by a shared key provided by the network administrator. LOT uses existing communication between network blocks to detect the potential for creating a tunnel (see Section 4). The rationale is that without communication, there is no profit in establishing a tunnel. Thus, we define the following: Definition 3.1. Two network blocks Net1 , Net2 are τ -periodically communicating if in any interval of length τ , at least one message is sent from s ∈ Net1 to a destination d ∈ Net2 or vice-versa. 3.2. Adversary Model

LOT is designed to provide security against ‘blind’ adversaries, who are able to send spoofed messages (i.e., messages with forged source address), but do not learn anything about the contents of messages sent to others. LOT assumes α-neighborhood adversaries: informally, we say that an adversary Adv is an α-neighborhood adversary w.r.t. a network block netblock, if the adversary can only receive messages sent to α ∈ [0, 1) portion of the addresses in netblock (i.e., wishes to take over a larger network block), as illustrated in Figure 6. Let Addr(Adv) denote the set of addresses that the adversary Adv conEve NetE trols. For any network block netblock GWA 1.2.3.0/25 we assume that either netblock ⊆ NetA Addr(Adv), i.e., entire block is corrupt, 1.2.3.0/24 or |netblock ∩ Addr(Adv)| ≤ α, i.e., adver|netblock| sary controls at most α portion of the addresses in the block, where α is typ- Fig. 6. α-neighborhood adversary. Eve controls only NetE but tries to form a tunnel specifying that she conically 12 or 34 . This assumption appears trols the entire NetA (α = 12 ). reasonable since network addresses are typically assigned either in consecutive blocks or as random samples from a large set (e.g., by DHCP). Formally, the adversary, Eve, controls a set of corrupt hosts and receives a message only if its destination is one of the corrupt hosts (i.e., adversary is blind). The adversary can send a message from any corrupt host and specify any source (i.e., a spoofing adversary). Similarly to messages sent by non corrupt entities, a message sent from a corrupt host, s, to a destination, d, would reach s.next(d). Note that adversary control of the network gateway, as illustrated in Figure 6, is equivalent to control of all hosts in its network, i.e., all hosts in NetE are corrupt. Definition 3.2. We say that two network blocks Net1 , Net2 are τ well-connected if the following hold: (1) Net1 , Net2 are τ -periodically communicating. (2) Eve is an α-neighborhood adversary w.r.t. every network block (not necessarily assigned to a LOT gateway) that contains either Net1 or Net2 , but not both. Two LOT gateways, G1 , G2 , are τ well-connected if NB(G1 ), NB(G2 ) are τ wellconnected. Two hosts, h1 , h2 , are τ well-connected if they are not corrupt, and for every two LOT gateways, G1 , G2 , s.t. G1 ∈ h1 .next(h2 ), G2 ∈ h2 .next(h1 ): G1 , G2 are τ wellconnected. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.


A:9

3.3. Security Requirements

We list the security properties that we require from LOT, Section 8 presents the corresponding proofs. 3.3.1. Packet Source Authentication (No Spoofing). Consider a run of LOT with a blind α-neighborhood probabilistic polynomial time (PPT) adversary. Let s, d be two τ wellconnected hosts such that s.next(d) ∩ d.next(s) = ∅, and there exist two LOT gateways Gs ∈ s.next(d), Gd ∈ d.next(s). Let n denote LOT security parameter; there exists a polynomial function t(n) such that if d receives a message m that was sent by a host h and specifies a source address s after time t(n), then except with negligible probability in n, the following holds:

(1) if s ∈ NB(Gs ), d ∈ NB(Gd ), then h ∈ NB(Gs ) ∪ NB(Gd ). This condition holds in Figure 5 where Gs = A and Gd = E. (2) otherwise, h 6∈ (NB(Gs )∪NB(Gd ))\(NB(Gs )∩NB(Gd )). Consider a modified version of Figure 5 where E does not run LOT. For this network topology, the condition holds and Gs = A and Gd ∈ {B, C, D}. 3.3.2. Confidentiality. Intuitively, this requirement ensures that use of LOT does not leak information on the content of communication between two hosts. We follow the cryptographic approach and require that a blind adversary will not be able distinguish which of two messages is sent from one host to another: the confidentiality requirement is satisfied if for every blind PPT adversary and two non corrupt hosts s, d, the following indistinguishability experiment returns 1 with probability at most 21 +negl(n) where n is a security parameter and negl a negligible function.

(1) (2) (3) (4)

The adversary chooses two messages, m0 , m1 and sends them to s. s chooses uniformly a bit b and sends d the message mb . Protocol and adversary execution. The adversary outputs b0 .

The experiment returns 1 if b = b0 , otherwise 0. 3.3.3. Availability. Let s, d be two τ well-connected hosts. For every α-neighborhood PPT adversary, and a message m sent from s to d at time t, it holds that: the probability that d does not receive m until time t + δ · hops(s, d) is at most 1 − (1 − )hops(s,d) + negl(n), where negl is a negligible function and n a security parameter. 4. OPPORTUNISTIC GATEWAY DISCOVERY

A stateless handshake precedes establishment of every LOT tunnel. The handshake protocol consists of two main phases: — Hello Phase: the two gateways detect the potential for establishing a LOT tunnel, and each gateway identifies the network block ‘behind’ it. In this section we present this phase. — Network Block Validation Phase: each gateway ‘proves’ that it can intercept packets sent to the network block behind it, i.e., the gateway ‘controls’ that network block. The network block validation phase is presented in Section 5. At the end of the handshake each gateway receives a proof (from the other gateway) that the validation succeeded and a tunnel is established. Perhaps the first question about an opportunistic tunneling protocol design is how two protocol supporting parties discover each other without a significant overhead (since there is no preliminary tunnel configuration). In this section we answer this question. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:10


Derived from our guidelines presented in Section 2, we have three requirements from the discovery method: Early discovery. A LOT gateway must be able to detect peer LOT gateways efficiently, within reasonable time since setup. Efficient discovery. LOT gateways must not misspend much resources trying to establish tunnels with networks whose gateways do not support LOT. Prevention of DoS attacks. The discovery mechanism is done with unauthenticated, arbitrary, peers. Therefore we must design it to be resilient to DoS attacks. In particular, the discovery protocol must not amplify an attacker’s capabilities (e.g., by providing disproportionately long responses) to prevent abuse in reflection attacks. 4.1. Design

LOT is triggered by a single gateway, GWA , when it forwards a packet from HostA behind it, to HostB , whose IP address does not belong to one of the network blocks with whom GWA has already established a LOT tunnel; see message A in Figure 7. GWA begins the handshake by sending a Hello Request message to HostB . This allows GWB , the first LOT gateway on the Hello message route, to intercept the Hello Request and respond; see messages B and C in Figure 7. To limit LOT’s overhead due to handshake requests, GWA sends a Hello Request only with rather low probability p (e.g., 0.01 or 0.001) per forwarding of packet to a destination (HostB ) without an established tunnel. HostA

GWA (key kA)

GWB (key ktime ) B

HostB Time

A. DestIP: HostB; arbitrary packet sent from HostA to HostB cookieA ← PRFkA(HostB||timeA) B. DestIP: HostB ;handshake hello request, cookieA, timeA, netblockA Intercepted C. SourceIP: HostB, DestIP: IPB; handshake hello response, cookieA, timeA, netblockB Verify: cookieA = PRFkA(HostB||timeA) ?

Fig. 7. Hello phase. The dashed arrow marks a packet blocked from the destination.

The Hello Request contains a description of the network block behind GWA and a cryptographic cookie - cookieA , which is the output of a pseudo random function (e.g., AES [Daemen and Rijmen 2002]) computed over the destination address and the current time. A network block is described by a tuple (base-address, l) where baseaddress is a network address (32 bits for IPv4, e.g., 128.1.2.3), l is the number of bits in the ‘network part’ of the address; i.e., the address block contains all addresses with the same l most-significant bits as base address. We use the familiar CIDR notation, base-address/l. A direction flag d extends the network block description to specify whether the address block is indeed base-address/l or its complement, i.e., the entire address space except base-address/l and Martian addresses (see [IANA 2002]). This extension allows establishment of tunnels between GWA and GWB as in Figure 8, where GWA is GWB ’s gateway to the Internet, but, traffic from GWB to GWC is not routed via GWA . In this scenario GWA informs GWB that it controls the entire address space except its internal address block, 76.42.0.1/16 (Martian addresses are excluded automatically). When GWB intercepts the Hello Request message, it replies with a constant (configurable) probability q (which is typically close to 1). This implies that the expected ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.


A:11

number of packets forwarded by GWA to the network behind GWB or vice-versa until 1 the Hello phase initiates is pq (assume similar p, q values in both gateways). A value of q < 1 makes abuse of LOT detection mechanism as an amplifier in reflection DoS attacks non attractive for attackers since even TCP servers provide a better amplification ratio (when the attacker sends a spoofed SYN packet). Therefore, we believe that abusing LOT for such indirect attacks is not a vivid threat. When GWB decides to respond 3 , it sends a Hello Response; see message C in Figure 7. The Hello Response, similarly to the Hello Request, contains a description of GWB ’s network block. The response is authenticated by GWA ’s cookie, which is attached. Furthermore, the response echoes the arguments used by GWA to create the cookie (HostB , timeA ); this allows the initiator (GWA ) to authenticate the cookie by reconstructing it, without keeping state. Additionally, GWA verifies that the response is not too old, i.e., timeA ∈ [current time − max delay, current time]. The stateless approach provides protection against denial of service attacks by resource exhaustion (such as SYN clogging on TCP servers [Eddy 2007; Lemon 2002; Harris and Hunt 1999]). Additionally, as an optimization, the response contains cookieB , a cryptographic cookie created by GWB . cookieB is used in the following network block val- LOT GW Internet ISP 76.42.0.2 idation phase, which we present in Sec- Out: In: 76.42.1.1/24 Router LOT GW (without LOT) tion 5. Out: 89.56.9.3 In: 76.42.0.1/16 When a series of LOT gateways exists GW (without LOT) on the route between two communicatOut: 76.42.0.3 ing hosts (HostA , HostB ), LOT would esIn: 76.42.2.1/24 tablish hop by hop tunnels (see tunnel A and tunnel B in Figure 3), i.e., a tunnel Fig. 8. An example of a network topology where a dibetween every two sequential LOT gate- rection flag is necessary. ways. This property follows from our design: since the node who handles the hello messages, and conducts the reminder of the handshake (see Section 5), is the nearest LOT gateway. B

A

C

4.2. Empirical Measurements

We investigated the effect on performance when a LOT gateway is flooded with spoofed handshake Hello Request messages which specify false network blocks. Such a DoS attack would cause the gateway to send Hello response messages. As we noted earlier, when q < 1, other network services (e.g., TCP servers) are better amplifiers for reflection DoS attacks. However, such flooding attack may still be used as a DoS attack vector on the LOT gateway and its network since the responding gateway (victim) would still create cookies (i.e., output of a cryptographic function, in our prototype AES [Daemen and Rijmen 2002]) and send Hello Response messages (message C in Figure 7). This is the maximum per-packet processing that an unauthenticated attacker can cause a LOT gateway to perform; therefore, the discovery mechanism is the most DoS vulnerable mechanism on LOT gateways. Consider the network topology in Figure 1, assume that only GWA deployed LOT and use Eve to flood GWA with spoofed Hello Requests that specify a random network 1 of other block. Eve’s bandwidth varies between measurements and was at most 10 links’ bandwidth which is 100Mbit/second. In addition to the processing that these messages caused GWA to perform, they also loaded the link between GWA and GWB . To isolate the effect caused by the Hello Request messages flood on GWA itself, we also 3 GW B

also verifies that there is not an already existing tunnel to HostA .


A:12



tested the effect of the attack when q = 0, i.e., when every one of Eve’s requests was discarded; we use this measurement as a base line for comparison. We measured the transfer time of constant data over a TCP connection (from Alice - server, to Bob client) and used it as indication to the effect of the attack. Initially we measured the attack’s influence when q = 1; i.e., when GWA re11 q=0 10 sponds to every LOT Hello message that q = 0.7 9 q=1 it receives; then, we conducted the test DNS reflection (1-1 ratio) 8 again when q = 0.7, where GWA re7 6 sponds only to one of several LOT Hello 5 messages that it receives. Figure 9 il4 lustrate our results. We also compared 3 these results with those of a weak DNS 2 0 2 4 6 8 10 reflection attack (1-1 ratio) where Eve Eve’s bandwidth in Mbit/sec sends a SYN packet to a TCP server that also runs on GWA (e.g., SSH), Figure 9 indicates that when q < 1 common net9. Effect on existing connection when a LOT work services can be abused by attack- Fig. gateway flooded with (spoofed) hello requests. The ers to amplify their abilities better than graph provides the confidence interval at a level of LOT. 95% for each measurement. 5. NETWORK BLOCK VALIDATION

LOT validates that a gateway controls a network block by ensuring that it is able to intercept traffic sent to that network block. The validation process is a challenge response protocol with several iterations; each iteration ensures that the responder controls a specific random address within the network block. However, the protocol validates only a portion of the addresses and not the entire network block (to avoid a significant overhead), later in this section we analyze the security and efficiency of this approach. The protocol validates simultaneously both endpoints; when it completes successfully, each gateway (e.g., GWA ) is provided with proof, issued by the other gateway (GWB ) that it controls a particular network block. Later, this proof is used as credit to establish a tunnel between the validated gateways. Once a tunnel is formed, each gateway tags traffic that it forwards to the peer gateway’s network block; this tag proves that the packet was not spoofed. In Section 7 we provide the details of this method. The network block validation protocol is designed to avoid possible DoS attacks. In particular, LOT gateways do not keep state when validating a network block and send at most a single packet in response for every packet that they receive. 5.1. Design

We now present the network block validation protocol performed by two peer LOT gateways. Assume that each gateway is aware of the network block that the other gateway claims to control and that both gateways agreed on n, the number of iterations required 4 . To avoid DoS threats we set a global constant nmax , and require that n ≤ nmax . Additionally, in order to avoid loading the network, we require that the prob1 ability to initiate the handshake, p (see Section 4), is at most 2nmax , since the number of packets sent during the handshake (by both gateways) is no more than 2nmax . Figgateway specifies the number of iterations it demands, n0 in the Hello Response message. The receiving gateway (the initiator) then decides the number of iterations it requires (according to the network block specified in the Hello Response) and sets n to be the maximum between them. The partner verifies that indeed n ≥ n0 .

4A



A:13

ure 10 illustrates the validation process for GWA and GWB , behind the gateways are NetblockA and NetblockB (respectively). HostA

GWA (timeA, key kA)

GWB (timeB, key timekB)

HostB Time

While (iA < n) or (IB < n) do : IPA , cookieA ← FkA(netblockB, timeA, iA, n) A. SourceIP: IPB DestIP: IPA, destPort: LOT_PORT; n, iB, iA, timeB, cookieB, timeA, cookieA, netblockA

Intercepted

Response Verification: IPB ,CookieB = FkB(netblockA, timeB, iB, n) ? Time() - Δmax < timeB < Time() ? Increment: iB = iB + 1 IPB ,CookieB ← FkB(netblockA, timeB, iB, n) Intercepted

B. SourceIP: IPA DestIP: IPB, destPort: LOT_PORT; n, iA, iB, timeA, cookieA, timeB, cookieB, netblockB

Response Verification: IPA ,CookieA = FkA(netblockB, timeA, iA, n) ? Time() - Δmax < timeB < Time() ? Increment: iA = iA + 1

Fig. 10. Network block validation phase. The function Time() returns the current time and ∆max is the maximal time interval allowed for the validation session.

The network block validation protocol consists of n steps. At every step of the validation, each gateway sends one packet to a random address in the network block claimed to be of the other gateway, the packet also contains a random cookie which is the challenge: if the gateway indeed controls the network block, then it can intercept the challenge (packets A and B in Figure 10) and respond with the cookie back to the source. The destination address and cookie are derived using a pseudo-random based function, F , according to the network block description, the time that the network block validation began, the iteration number, i, and the total number of iterations, n. Details of the derivation function are available in an online technical report A.1. Each challenge message also provides a response to the previous challenge: a challenge message contains the two cookies used as challenge and response as well as the arguments used as inputs for the function F to create them. When a gateway intercepts a challenge message it first validates the response specified within, i.e., checks that its own cookie is correct by reconstructing it (the cookie is not saved to avoid from keeping state during the handshake). In order to reconstruct the cookie, the gateway uses its secret key and the parameters used to create the cookie which are also extracted from the response (see Figure 10). This ensures that the sender received the previous challenge. The responder also compares the current time with the time specified in the challenge (the time that the validation session begun), validating the challenge is not too old. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:14


After the responder successfully validates the response, it chooses a destination address in the remote network (using the function F ) and sends a new challenge that specifies the destination host of the previous challenge as source. The new challenge message also echoes the previous cookie (i.e., is a response to the previous challenge) and the corresponding parameters (time, n and i), to allow the recipient to validate the response. See packets A and B in Figure 10. This process of challenge and response is repeated n times, where n is chosen as analyzed in Subsection 5.2 below. A gateway may require a different number of iterations for different networks (e.g., depending on their size). The values of n and the current iteration number are extracted from the response (see packets A and B in Figure 10); since they are inputs of F , they can not be forged. 5.2. Analysis

We now provide a security analysis for the network block validation protocol with regards to the α-neighborhood adversary (see definition in Section 3.2). We calculate the probability that an attacker running against a LOT gateway successfully completes the validation process for some network block of size x, while in reality attacker only controls l ≤ x · α of the addresses in network block. The probability that the attacker’s fraud is not discovered in a single step, is the probability of choosing a host controlled by the attacker, i.e., xl ≤ α. Furthermore, F ’s arguments are constant per iteration within a specific validation session. Namely, ci , the i’th challenge within a validation session, does not depend on the responses sent by the gateway being validated. This ensures that the responder is unable to influence the challenges. Moreover, even if the responder convinces the validator to send multiple challenges to the same round, e.g., by sending multiple responses to the previous round, all challenges (c1 i , c2 i , ...) would be identical. Therefore, if the responder is unable to intercept a challenge in a round, then it is unable to any challenge of that round. The probability pf that the attacker’s fraud is not discovered after n steps is: pf = l n ≤ αn . Hence, n = dlogα (pf )e iterations are required to obtain the probability of x failure pf . For example, if α = 0.5 and pf = 0.00001, then n = 17. Namely, 17 iterations (17 challenges) are required to verify a gateway’s claim with probability of 0.99999, even if it controls up to half of the addresses in the network. 5.2.1. Time Analysis. Network block validation iterations are asynchronous and each iteration requires one gateway to gateway round trip time (RTT) to complete. Assume that RTT is 200ms as typical for the Internet and 17 iterations (as in the example above); then this phase completes in less than 3.5 seconds. We stress that LOT handshake does not halt communication between peers; LOT only starts to actively influence communication (and filter spoofed traffic) when the handshake completes and a tunnel is established. 6. MECHANISMS AGAINST DENIAL OF SERVICE

In this section we present mechanisms that utilize source address spoofing prevention to provide protection against DoS attacks. Throughout this section we assume that the LOT gateways have successfully completed the network block validation protocol described in Section 5. Additionally, we assume that traffic from one gateway to the other is tagged; this allows the receiving gateway to filter spoofed packets and to distinguish between different source networks. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.


A:15

6.1. Local and Remote Quotas, Priorities and Filters

LOT packet encapsulation identifies the source network, this allows the receiving gateway to establish per network queues and quotas. When a DoS attack occurs, only the quota allocated to the attacker’s network is exceeded 5 . Consequently, only traffic routed from networks where the attacker is present may be hindered. Furthermore, when under a DoS attack, a LOT gateway is able to give priorities to incoming traffic; encapsulated LOT traffic will be given high priority and will not undergo aggressive one-sided filtering (since LOT ensures that it is not spoofed). This provides an additional incentive for network administrators to deploy LOT. Moreover, LOT allows gateways to establish near source quotas. Namely, GWA is able to send GWB the quota that it allocates to traffic originating from GWB ’s network block and request GWB to enforce that quota as well. If the remote gateway (GWB ) accepts the request, then it will shape the traffic itself and excess traffic will be dropped by its source; hence, the load on the link between the two gateways will be reduced. Once GWA notifies GWB of the quota it allocates for GWB ’s network block, it is in the interests of GWB as well to enforce the quota (save its resources) and not just an act of good faith (since otherwise, GWA would discard the excess traffic). Ingress filtering and near source quotas filter packets before leaving the origin network; however, these techniques differ in essence. First, ingress filtering copes only with spoofed traffic while near source quotas cope with excess traffic (regardless of the specified source); second, ingress filtering is deployed without support of the destination network while near source filtering relays on gateways cooperation. Finally, near source filtering allows the sending gateway to avoid waste of bandwidth, thereby providing local benefits to deployers; ingress filtering provides a global benefit, i.e., the more ISPs that deploy ingress filtering, the harder it is to perform IP spoofing, but until almost all ISPs perform ingress filtering attackers will often be able to perform it. These two mechanisms can and should be deployed together. Despite significant benefits (see empirical results below), the near source filtering mechanism is vulnerable for abuse by attackers who were able to obtain LOT credentials or complete the LOT handshake. Therefore, requests for near source quotas/filtering must be handled with excess care. First, such requests are more strongly authenticated, i.e., using cryptographic authentication mechanisms, not merely by attachment of temporary tags (like other encapsulated packets). Specifically, the requests contain a cryptographic MAC [Goldreich 2001] computed using the session key which is the last cookie exchanged during the network block validation phase. Furthermore, the two gateways must have established credentials for a substantial amount of time (e.g., one week) to ensure that the requester does not have only short term possession of its network block. During that time period, a gateway filters spoofed packets and shapes incoming traffic according to the specified (tunnel) tag; however, it does not conduct near source traffic shaping (for outgoing traffic). LOT detects when a peer gateway looses control over its network block with the tunnel re-validation mechanism (see details in Section 7.1); in this case the tunnel is teared down. Lastly, these remote filtering and traffic shaping rules have short TTLs (e.g., few hours); this provides additional protection from network block possession loss and reduces the filtering overhead at the peer gateway. Similarly, a gateway can request, in the form of a firewall rule, to filter specific traffic by its source, destination port, or other characteristics. The near source filtering technique is used when a gateway identifies an attack on its network, either by monitoring the traffic (e.g., with IDS) or by insights on the network topology (e.g., identify DNS 5 Separate

quota and queue are allocated to all network blocks with whom there is no tunnel.


A:16


requests sent to arbitrary entities). Near-source filtering mechanisms were proposed in several previous works, including [Ioannidis and Bellovin 2002; Huici and Handley 2007; Wang et al. 2007], we discuss these mechanisms in Section 9.3. Near source traffic shaping/filtering techniques allow the receiving-end gateway (GWA ), not the network, to decide which packets will be dropped, as recommended in [Lakshminarayanan et al. 2004]. By ‘pushing’ traffic filtering nearer to the source, we significantly reduce the traffic over the entire route, and reduce the total number of filters required at the gateway, protecting a network from a DDoS attack. We investigated how effectively these mechanisms mitigate DoS attacks. Figure 11 illustrates the network topology we used in our measurements. We measured the transfer time of a file from Alice to Bob while Bob is flooded with packets sent by the attacker (Eve). Three scenarios were considered: — First, GWD does not deploy LOT (i.e., normal conditions). — Second, GWD deploys LOT and establishes two tunnels: one with GWS and another with GWE . In this scenario, GWD allocates a quota of 20Mbit/sec for incoming traffic from each tunnel. — Third, GWD also requests GWE to enforce the quota allocated to its network block (i.e., 20Mbit/second).

10 Alice

Eve

GWS c

GWE

100 100

R

60

GWD

40

Bob

Fig. 11. Environment for testing DoS mitigation techniques. Each link specifies its capacity in Mbit/second, except for Eve’s link whose capacity varies throughout measurements and marked by c.


The results, illustrated in Figure 12, indicate that placing quotas at the destination gateway moves the bottleneck from the link between GWD and Bob to the link between R and GWD . Placing the quota near the congesting source, at GWE , limits Eve’s bandwidth to only 20Mbits/second and mitigates the attack. Furthermore, Figure 12 shows that when there is no attack (i.e., Eve’s capacity is 0), LOT encapsulation has a small overhead; this is also verified in our performance evaluation in Section 7.4. To further limit LOT’s overhead under normal conditions, one can set up potential LOT tunnels in advance (when the network is not under attack); only when a gateway suspects a DoS attack (e.g., notices excess traffic) it notifies the remote party to encapsulate traffic and employs the proposed mitigations 6 . 70 65 60 55 50 45 40 35 30 25 20

Without LOT Quotas at the dest gateway Near source quotas

0

20

40 60 80 Eve’s bandwidth in Mbit/second

100

Fig. 12. Effect of flooding attack on a TCP connection when different mitigation mechanisms are employed.

6.2. Inter-Gateway Congestion Detection

LOT also employs a congestion detection mechanism. The congestion may be due to legitimate traffic load or a deliberate DoS attack, such as the Coremelt [Studer and Perrig 2009]. The Coremelt attack generates excessive traffic between zombies located in various points on the Internet, overloading a specific core router. 6 When

using this setup LOT does not satisfy the no spoofing requirement as defined in Section 3.3.1 since the tunnels are not established.



A:17

A LOT gateway monitors the amount of traffic it receives 7 from each tunnel and periodically informs the corresponding peer gateway; when a gateway receives a valid notification (validity check is similar to that of near source quota requests) it compares the specified amount with the amount of data sent to the notifier’s network block. If the notification indicates that a significant portion of the traffic did not reach the receivingend gateway, then a congestion on the route is detected; in this event a gateway can actively relieve the congested route. One simple act, is arbitrarily discarding packets sent to the notifier’s network block at the sender’s gateway 8 ; we used the Coremelt attack simulator generously provided by the authors of [Studer and Perrig 2009] to test the effect of this method during the attack. Similarly to their measurements, we assumed that bots distribute between ASs as in the GT-DDoS attack, and used the portion of ASs that experience packet loss as an indication to the destructiveness of the attack. We integrated LOT into the Coremelt simulator: random Fig. 13. Coremelt simulation results when simulatan attacker with 128 kbps per bot. The graph proASs deployed LOT, when a LOT deploying vides the confidence interval at a level of 95% for each ing AS identifies a congestion on a tun- measurement. nel to some other LOT deploying AS it randomly discards exiting traffic (on that tunnel). The probability that a gateway discards a packet equals the portion of traffic that did not reach the receiving-end gateway during an initial calibration phase. We conducted our measurements for different LOT penetration rates. Our results, illustrated in Figure 13, indicate that when penetration rate is significant, it is much harder to perform the Coremelt attack. For example, when LOT is deployed on 70% of ASs, in order to cause loss at 80% of the ASs, the attack requires a triple number of bots. 7. DESIGN AND IMPLEMENTATION: ENCAPSULATION AND FILTERING

When the handshake completes and a tunnel is established, LOT begins to provide security benefits. In this section we first describe how LOT derives the parameters for the tunnel: the tag and the minimal MTU across the tunnel. Then we describe LOT packet structure and discuss how LOT encapsulates and decapsulates traffic. Lastly, we present an empirical performance assessment of LOT’s tunneling mechanism. 7.1. Tunnel Establishment, Maintenance and Re-Validation

When the handshake completes, the last cookies that the participating gateways exchange are saved and used as session keys. LOT derives outgoing and incoming periodic tags from the two session keys (i.e., the last cookie sent and received). The periodic tags are derived simply by: PeriodicT ag = PRFSessionKey (i) where PRF is a pseudo random function and i is the current period index (calculated according to the difference between the current time and the tunnel creation time). 7 If

there are multiple gateways to a network, the gateway must query all other gateways for the traffic they received. 8 Further research is required to conclude the appropriate act in case congestion is detected.


A:18


7.1.1. Credentials Expiration and Renewal. Every constant time interval, T , the tunnel is re-validated and the session key refreshed. This happens only if during the interval T the tunnel was active; otherwise, the credentials expire and the tunnel is teared down. Namely, the network block validation is repeated, but only if at least a constant number of π encapsulated packets where sent between the peers during the last period. The n challenges that each participating gateway sends during the re-validation session contain an additional authentication field which specifies the current (outgoing) periodic tag. This allows the recipient to validate that the remote peer does not change. When a challenge is not provided with a valid response within a reasonable delay it is resent (in contrast to the initial handshake, the sender keeps state); we allow up to r(n) ∈ Ω(n) retransmissions of the same challenge, before terminating this iteration of network block validation. If the periodic network block validation fails, a new validation session starts immediately; we allow up to R(n) ∈ Ω(n) consecutive failed validation sessions before terminating the renewal process 9 . When the process completes, new session keys are established (the current periodic tag is still used until it expires). 7.1.2. Tunnel Maximum Transfer Unit Discovery. Once periodic tags are created, the gateways perform an authenticated tunnel maximum transfer unit (TMTU) discovery protocol to detect the minimal MTU across the tunnel. This is similar to the classic path MTU discovery process described in [Mogul and Deering 1990]. However, in the authenticated version each packet begins with the periodic tag. This allows the recipient of the ICMP [Postel 1981a] type 3 code 4 (host unreachable, fragmentation needed) feedback to validate its authenticity, since the feedback will also contain an echo of the periodic tag. ICMP messages are often blocked; therefore, LOT also supports an an authenticated binary search to discover the minimal MTU along the route. In this process gateways detect the TMTU by sending packets at different lengths (binary search) and detecting the longest size packet that receives a response from the remote gateway; packets and their responses are authenticated using LOT credentials to foil spoofed responses. The TMTU discovery process is repeated periodically to adjust the TMTU for changes in the network. When a packet that requires encapsulation reaches the gateway, it first checks whether the size of the packet with the addition of the encapsulation header would exceed the TMTU. In this case, if the do not fragment (DF) flag is set, then the gateway sends back to the host an ICMP fragmentation needed feedback, allowing the sender to learn the maximal size allowed (TMTU minus encapsulation header size). If the DF flag is cleared, then the gateway fragments the packet before encapsulation and sets the DF in each encapsulated fragment. This approach is known as pre-fragmentation and is adopted by some vendors (e.g., [Cisco Systems 2007]), it avoids in-tunnel fragmentation and related problems, e.g., see [Kent and Mogul 1987; Kaufman et al. 2003; Heffner et al. 2007; Gilad and Herzberg 2011]. 7.1.3. Tunnel Re-Validation. An attacker that obtains temporary control over a network block can set up tunnels with other LOT peers. When the attacker loses control over the network block, communication to and from the network block is disrupted until LOT tunnels are teared down (at the next periodic tunnel validation). Furthermore, in this case, the attacker will still be able to send spoofed packets specifying source addresses within that network block. 9 The lower asymptotic bounds on r(n), R(n) allow proof that LOT tunnels are teared down because of packet loss with negligible probability, see Section 8.



A:19

This threat is especially critical for small network blocks, where it is possible to obtain short-term DHCP leases over all or most of the consecutive addresses; this allows an attacker to pass the network block validation successfully. The tiny network block attack is also relevant for other opportunistic protocols, e.g., BTNS [Williams and Richardson 2008; Touch et al. 2008] that forms IPsec tunnels with single hosts. We provide a solution to this threat by re-validating LOT tunnels when a non encapsulated packet arrives from a host within a (small) network block. In this case the receiving gateway, GWA , discards the packet, but with probability q (the same probability of sending an Hello Response, see Section 4) GWA also sends a challenge to the source address. If the tunnel is still valid, then the remote gateway (GWB ) can intercept the challenge and respond. If it does not reply after ρ(n) ∈ Ωn2 retransmissions, as would be the case in the ‘tiny network block’ attack described above, GWA tears down the LOT tunnel. We allow only one re-validation session for a particular tunnel every ∆ > 0 seconds; in practice, ∆ is usually short and similar to the round trip time between tunnel endpoints. 7.2. Encapsulated Packet Structure

LOT tunnels are ‘transparent’: encapsulated traffic keeps the original source and destination addresses. This allows load distribution between multiple gateways of a network such as NetblockA in Figure 4. However, the IP header and data are modified when LOT encapsulates a packet. The notable changes to the original packet are described below: IP flags. LOT does not allow fragmentation of encapsulated packets within a tunnel. Therefore, in encapsulated packets the DF is set and the MF flag is unset. Transport layer protocol. The field (specified in the IP header) is modified to indicate that the packet is encapsulated by LOT. Encapsulation is not always mandatory: at certain times LOT gateways may pass incoming non-encapsulated traffic even if it specifies a source address that belongs to a validated network block (e.g., to eliminate LOT’s overhead while not under DoS attack). The protocol field distinguishes between such non LOT traffic and encapsulated packets which should be decapsulated first. Furthermore, the change in the protocol field ensures that if an encapsulated packet reaches its destination without proper decapsulation, it will be discarded and will not reach the application. LOT header. A LOT header is attached to the packet, its most significant field is the outgoing periodic tag. Additional fields include data required for reconstruction of original packet (original IP flags and transport protocol) and optionally parameters that allow the receiving-end gateway to reconstruct the session key (using PRF and his secret key) and the specified tag. Tag reconstruction allows the gateway to validate that the packet is not spoofed without keeping state (stateless one-way tunnel) similarly to challenge reconstruction during the network block validation phase 10 . We provide a full description of the LOT header as well as further details on the stateless option in Appendix A.2. 7.3. Tunneling

This subsection describes LOT encapsulation and decapsulation mechanisms. 7.3.1. Encapsulation. When a gateway forwards a packet from a host in its network, it first identifies whether there is a tunnel established with the packet’s destination. If 10 When

using this setup LOT does not satisfy the non spoofing requirement as defined in Section 3.3.1 since only one side can filter spoofed traffic.


A:20


found, the gateway checks whether the packet matches a (near source) quota or filter request of the receiving-end gateway (see details in Section 6.1). If there is a match, then the gateway processes the packet according to the quota or filter; otherwise, the gateway verifies that the corresponding encapsulated packet would not exceed the TMTU. If the packet is too long, the gateway either sends an ICMP feedback to the host or performs pre-fragmentation, depending on the DF flag. If the destination IP address is not included in any validated address block (see Section 5), then LOT forwards the packet as it was received and sends a Hello Request with probability p (see Section 4 for details). 7.3.2. Decapsulation. When a gateway receives a packet to forward to a host in its own network block, it checks whether a tunnel is established with the packet’s source. If there is no tunnel, or encapsulation is not mandatory (and the packet is not encapsulated), then it forwards the packet to the destination. Otherwise, the gateway decapsulates the packet, and forwards to the destination only if it specifies a valid tag. If the packet is not encapsulated (but should be), then LOT re-validates the tunnel with probability q. 7.4. Performance Evaluation

We used our prototype implementation to evaluate the performance of LOT tunneling mechanism in the network environment illustrated in Figure 14. Our evaluation compares LOT tunneling with plain communication (no tunnel) and IPsec tunnel (Linux built in implementation) with HMAC SHA1 for authentication and null encryption (i.e., authentication only). We tested the effect of using LOT, IPsec and plain communication on a 10 10 TCP connection when the link between Alice Bob 100 the networks is loaded with legitimate GWB 100 c GWA traffic. Both gateways, GWA and GWB in Barbara Al Figure 14, encapsulated the communication using LOT, IPsec (HMAC authen- Fig. 14. Performance evaluation environment. Link tication) or simply forwarded it without capacities are specified in Mbit/second, except for Al’s encapsulation (plain communication). In capacity, which is specified as c, since it varies beorder to load the bandwidth, we sent tween measurements. UDP packets at different rates from Al to Barbara; we used two different packet lengths: first, we tested with 1400 bytes long packets (to avoid fragmentation related overheads); second, we tested for 300 bytes long packets to illustrate what we consider a typical deployment scenario for LOT: DNS servers, which usually send and receive rather short packets. We evaluated the performance by timing the transfer time of a file from Alice to Bob. Our LOT prototype uses the netfilter open source package in order to capture and handle (encapsulate/decapsulate) packets. The use of this package comes with a certain overhead as it is not built into Linux packet processing. In order to measure LOT’s overhead, we used netfilter to capture and immediately forward (without handling) packets when testing the plain communication scenario. Before running the tests on LOT and IPsec, we ensured that the tunnels are already set up to avoid the initial overhead. The results, illustrated in Figure 15, show that LOT’s overhead is rather small comparing with IPsec, but is slightly larger than no tunneling at all 11 . The more packets 11 The

relative overall improvement in results from those presented in Figure 12 (e.g., compare when Al and Eve’s capacities are 0) is due to transition to a full physical model (for the performance evaluation).



A:21



sent between the networks, the higher the load on the network gateways and the more distinct difference in performance between plain communication, LOT and IPsec becomes. When the packet size increases, all mechanisms perform better (since there are less packets). However, LOT and plain communication improve better than IPsec since they perform constant time processing on each packet while IPsec performs HMAC authentication; i.e., processes all packet bytes. Finally, we measured the average latency that LOT encapsulation and decapsulation add and found that it is less than 10 microseconds per-packet on 3GHz dual core PC processors (used as the tunnel gateways). 30 Plain communication LOT IPsec

25 20 15 10 0

10

20 30 40 Al’s bandwidth in Mbit/sec

50

(a) Traffic load created by 300 byte long (application layer data) packets.

30 Plain communication LOT IPsec

25 20 15 10 0

10

20 30 40 Al’s bandwidth in Mbit/sec

50

(b) Traffic load created by 1400 byte long (application layer data) packets.

Fig. 15. Plain communication, LOT and IPsec performance comparison.

8. SECURITY ANALYSIS

In this section we discuss the security properties of LOT; the following subsections sketch the proofs for the requirements presented in Section 3.3 according to the communication and adversary model presented in Sections 3.1, 3.2. 8.1. Packet Source Authentication (No Spoofing)

The proof that LOT meets the no spoofing requirement (see Section 3.3.1) has three steps: first, in Lemma 8.1 we show that there is almost always a LOT tunnel established between two τ well-connected peer LOT-gateways (see definition in Section 3.2). Second, we show in Lemmas 8.2, 8.3 that if Gs and Gd ∈ Gs .next(d) are two τ wellconnected peer LOT-gateways that established a tunnel, then a message m that specifies a source s ∈ NB(Gs ) and reaches its destination d ∈ NB(Gd ) can be sent by hosts in one of two specific address sets. Lastly, Theorem 8.4 proves the requirement. L EMMA 8.1. If G1 , G2 are two τ well-connected peer LOT-gateways, then there exists a polynomial t(n) such that the probability that there is no tunnel between G1 and G2 at time τ t(n) from beginning of execution is negligible in n, the number of iterations during the network block validation phase. P ROOF. The run-time is divided into periods where there is and is not a tunnel established between G1 , G2 . In the first part of the proof we show that there exists a polynomial t(n) ∈ O(n) such that a tunnel was established after time τ t(n) with overwhelming probability 12 in n. The second part of the proof shows that after a tunnel 12 An

event occurs with overwhelming probability if the probability that it does not occur is negligible.


A:22


was established once between two gateways, the probability that it is not established (i.e., teared down) at a particular later time is negligible. Let G1 , G2 denote the set of all gateways assigned to NB(G1 ), NB(G2 ) (respectively). Denote by p, q the minimal probabilities to send Hello request or Response for all gateways in G1 ∪ G2 . The tunnel is established when the handshake completes. The handshake initiates when a message is sent from a gateways in G1 to a gateway in G2 or vice-versa with probability of at least pq(1 − )2 ; i.e., both Hello Request and Response messages are sent and neither of them is lost. Next, the network block validation phase takes place: gateways of the two network blocks exchange 2n messages (challenges and responses), this phase completes if no message is lost, i.e., with probability of at least (1 − )2n . Thus, the probability pest , that a message initiates a successful handshake (and a tunnel is established), is at least pq(1 − )2n+2 . Since G1 , G2 are τ well-connected, NB(G1 ) and NB(G2 ) are τ periodically communicating (see Definitions 3.1, 3.2); therefore, in every interval of length τ , at least one message is sent from G1 to G2 or vice-versa. Let t˜(n) = n, at time τ t˜(n) there have been at least nτ τ = n messages sent between G1 and G2 . The handshake takes to 2nδ seconds to complete; let t(n) = t(n) + 2nδ τ , the probability that no tunnel was established until time τ t(n) = nτ + 2nδ is at most (1 − pq(1 − )2n+2 )n . It holds that 1 − pq(1 − )2n+2 < 1 (since 0 ≤ < 1); therefore, there exists a 0 < c < 1 such that (1 − pq(1 − )2n+2 )n < cn ; i.e., the probability that no tunnel was established is negligible in n. Once established, a tunnel is teared down if either a periodic validation session fails or the adversary actively starts a tunnel re-validation session that tears down the tunnel (see Section 7.1). We analyze these scenarios below; we begin with the periodic validation. Once every T seconds a periodic validation session begins, the session consists of up to R(n) iterations: in each iteration 2n challenges are sent, and up to r(n) retransmissions of each challenge are allowed. An iteration fails if at least one challenge does not receive a single valid response. The gateways in G1 , G2 control NB(G1 ), NB(G2 ); therefore, a challenge fails only if it or its response was lost, i.e., with probability of at most + (1 − ). For readability, let c ≡ + (1 − ); each iteration succeeds with probability r(n) of at least (1 − c )2n . The entire session fails (and the tunnel is teared down) if all r(n) R(n) iterations fail, i.e., with probability: pprd ≤ (1 − (1 − c )2n )R(n) . Every ∆ seconds, an adversary can actively attempt to tear down a tunnel by initiating tunnel re-validations (by sending a spoofed non encapsulated packet to one of the gateways), see discussion on Tunnel re-validation process in Section 7.1.3. In a tunnel re-validation a gateway sends a challenge to an address in the remote end of the tunnel that the other gateway should intercept; up to ρ(n) retransmissions are allowed. Since tunnel credentials are still valid, a re-validation fails only if for all ρ(n) retransmissions either the challenge or its is lost. Let l = |G1 ∪ G2 |, the adversary can initiate re-validations with every gateway; therefore, the probability padv that the attacker succeeds to tear down the tunnel by initiating tunnel re-validations in a particular period ρ(n) of ∆ seconds satisfies: padv ≤ lc . Tunnel establishment, periodic validations, and tunnel re-validation are discrete events that may occur once every τ, T and ∆ seconds respectively. We assume that T, τ ≥ ∆, Let k1 be the maximal integer such that T ≤ k1 ∆, and let k2 be the minimal integer such that τ ≥ k2 ∆. We view the state of the tunnel as a Markov process that transits between states every ∆ seconds, see illustration in Figure 16. Figure 16 illustrates a worst case analysis where where we assume that the adversary initiates tunnel re-validation every ∆ seconds (to tear down the tunnel) and exactly one packet



A:23

is sent between NB(G1 ), NB(G2 ) every τ seconds (to initiate the handshake). Additionally, in Figure 16 we assume that T = k1∆, i.e., periodic validation is as short as possible, and that τ = k2∆, i.e., messages (that may initiate the handshake) are as sparse as possible. Once a tunnel is established between a pair of gateways G01 ∈ G1 and G02 ∈ G2 , G01 and G02 inform the other gateways and a tunnel is set up between all pairs of gateways in G1 , G2 . Let πt , πnt denote the probabilities that there is and is not a tunnel between G1 , G2 ; i.e., the probability that the tunnel is in T.∗ and NT.∗ states (see Figure 16); the following invariant equations hold: (1) πt + πnt = 1 (2) πnt = πt · padv +

1 k1 πt

· pprd +

1 k2 πnt

· (1 − pest )

handshake completes

otherwise

T.1

otherwise

T.2

otherwise

otherwise periodic validation or re-validation fails NT.1

···

T.k1

NT.2

···

NT.k2

re-validation fails re-validation fails

Fig. 16. A Markov chain that represents the tunnel state. In T.∗ a tunnel is established, NT.∗ are states where a tunnel is not established.

From the two invariant equations, we conclude the value of πnt . πnt = (1 − πt )padv + (1 − πnt ) πnt =

padv + 1−

1 k2 (1

1 1 pprd + πnt (1 − pest ) k1 k2

1 k1 pprd

− pest ) + padv +

1 k1 pprd

1

πnt = 1+

(1)

1− k1 (1−pest ) 2

padv + k1 pprd 1

We use the bounds for pest , pprd , padv and Equation 1 to bound πnt and show that πnt is negligible in n: p +p p p 1 1 ≤ advpest prd = ppadv + pprd . We analyze separately ppadv , pprd πnt ≤ pest 1−(1−pest ) = 1+ est est est est 1+

padv +pprd

padv +pprd

and show that each of them is negligible, thus, their sum is negligible as well. lρ(n) 2 c First, ppadv ≤ pq(1−) 2n+2 . Since ρ(n) ∈ Ω(n ) (see ρ(n) definition in Section 7.1.3), est 2

≤

ln c pq(1−)2n+2

2

n n l l n c c pq(1−)2 (1−)2n = pq(1−)2 ( (1−)2 ) . n (c ) Since c < 1, limn→∞ (1−) 2 = 0, i.e., for large enough n there exists a 0 ≤ c n (c ) (c )n n l l n < pq(1−) that (1−)2 < c. Therefore, pq(1−) 2 ( (1−)2 ) 2 c , which is negligible. padv pest

=

< 1 such


A:24


Second, that

padv pest

≤

(1−(1−r(n) )2n )R(n) c pq(1−)2n+2

(1−)2n r(n) 2n R(n) (1−(1−c ) )

=

(1−)2n 1 )−1 . pq(1−)2 ( (1−(1−r(n) )2n )R(n) c

It is enough to show

≥ cn for some constant c > 1. Since r(n), R(n) ∈ Ω(n) (see

their definitions in Section 7.1.1), limn→∞

(1−)2n r(n) 2n R(n) (1−(1−c ) )

≥ limn→∞

(1−)2n 2n )n (1−(1−n c)

=

(1−)2 n limn→∞ ( 1−(1− n )2n ) . c

For any number a ≥ 0, the following inequality holds: (1 − a)n ≥ 1 − na (proof 2 (1−)2 (1−)2 n n n by induction). Thus, ( 1−(1− ≥ ( 1−(1−2n = ( (1−) n )2n ) n) ) 2nn ) . Since 0 ≤ c < 1: c

(1−)2 2nn = ∞. (1−)2 n ( 2nn ) ≥ cn . c

limn→∞ 2nnc = 0 and limn→∞ such that for large enough n,

c

c

Therefore, there exists a constant c > 1

L EMMA 8.2. Let s, d be two hosts, and Gs , Gd be two τ well-connected peer LOTgateways, s.t. Gd ∈ Gs .next(d) and the following holds: d ∈ NB(Gd ) ∧ s ∈ NB(Gs ); e.g., see gateways Gs = B, Gd = E in Figure 5. Let η denote the security parameter of the PRF used to create the tunnel session key and tags (see Section 7.1) and let λ denote the length of the tag. There exists a polynomial t(n) such that the following holds: assume that d receives a message m after time τ t(n) with source address s, then the probability that m was sent by a host in NB(Gs )∪NB(Gd ) is overwhelming in n, η and λ. P ROOF. Let h be a corrupt host s.t. h 6∈ NB(Gs ) ∪ NB(Gd ). Assume by contradiction that h, who is controlled by an α-neighborhood PPT adversary, Eve, is able to send the (spoofed) message m with source s that d will receive with non negligible probability. By Lemma 8.1, there exists a polynomial t(n) such that Gs , Gd have a tunnel established after time τ t(n) except with negligible probability in n; in the reminder of this discussion we assume that such tunnel is established. Since h 6∈ NB(Gs ) ∪ NB(Gd ), no gateway associated with NB(Gs ) receives m (to encapsulate); but a gateway associated with NB(Gd ) receives m before d. According to our construction of LOT in Section 7.3.2, that gateway does not discard m only if it specifies a valid PeriodicTag = PRFSessionKey (i); where SessionKey = PRFk (remote netblock||time||n||n). It follows that Eve can specify a valid tag with non negligible probability. We assume for simplicity that the length of SessionKey equals η. Let r ∈R {0, 1}η , it follows that Eve can either distinguish between the session key and r, or that Eve can distinguish between PRFr (i) and f (i) where f is a random function with output length identical to PRF. These events are negligible in the security parameters η, λ. L EMMA 8.3. Let s, d be two hosts, and Gs , Gd be two τ well-connected peer LOTgateways, s.t. Gd ∈ Gs .next(d) and the following holds: either s 6∈ NB(Gs ) or d 6∈ NB(Gd ) (but not both), e.g., see gateways Gs = A, Gd = B in Figure 5. There exists a polynomial t(n) such that the following holds: assume that d receives a message m after time τ t(n) with source address s, then the probability that m was sent by a host in NB(Gs ) \ NB(Gd ) ∪ NB(Gd ) \ NB(Gs ) is negligible in n, η and λ (see definition of η, λ in Lemma 8.3). The proof of Lemma 8.3 is similar to that of Lemma 8.2, except for the ‘location’ of the corrupt host h. Here we assume that h ∈ NB(Gs ) \ NB(Gd ) ∪ NB(Gd ) \ NB(Gs ). T HEOREM 8.4. LOT satisfies the packet source authentication requirement (see Section 3.3.1). P ROOF. Let l = hops(s, d) − 1; G denote the set {Gi }li=1 where G1 ∈ s.next(d), Gi+1 ∈ Gi .next(d). During the proof below we conduct a handful of set operations on network ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.


A:25

blocks associated with gateways in the set G; we omit the NB notation for readability. By our definition of the ‘next’ operation, there exists 0 ≤ l0 ≤ l such that for every 1 ≤ i < l0 , Gi ⊂ Gi+1 and for every l0 < i < l, Gi+1 ⊂ Gi (e.g., l0 = 2 in Figure 5). Let h denote the sender of a message with source address s that reaches d. If d ∈ / Gd , then l0 = l. In this case G1 ⊂ G2 ⊂ · · · ⊂ Gl . We apply Lemma 8.3 on every pair of sequential gateways and get there exists a polynomial t(n) such that if the message was sent after time τ t(n), then the sender h ∈ / Gl \ G1 . The polynomial t(n) is greater or equals (for large enough n) from all polynomials t0 (n) used when applying the lemma on each of the pairs; t(n) must exist since the number of pairs is finite. Similarly, if s∈ / Gs , then l0 = 0 and h ∈ / G1 \ Gl . Namely, in these cases the no spoofing is satisfied. Therefore, we assume that s ∈ Gs and d ∈ Gd ; in this case, 0 < l0 < l and by Lemma 8.3: h ∈ / Gl0 \ G1 and h ∈ / Gl0 +1 \ Gl . Consider the gateways Gl0 , Gl0 +1 (gateways B, E in Figure 5): by our construction, s ∈ Gl0 , d ∈ Gl0 +1 ; from Lemma 8.2 we obtain another restriction on h: h ∈ Gl0 ∪ Gl0 +1 . We combine the restrictions on h: h ∈ (Gl0 ∪Gl0 +1 )\((Gl0 \G1 )∪(Gl0 +1 \Gl )) = G1 ∪Gl . Since NB(G1 ) = NB(Gs ) and NB(Gl ) = NB(Gd ), we get that h ∈ Gs ∪ Gd . Since we use Lemmas 8.2, 8.3, all restrictions on h hold except with negligible probability in LOT security parameters (n, η, λ) as the requirement allows. 8.2. Confidentiality

In this subsection we sketch the proof of the confidentiality requirement presented in Section 3.3.2. Consider a run of the protocol and let V be the adversary’s view; i.e., the set of all messages that the he receives. For every message m sent from one host to another, LOT does not change the destination address; the only hosts that receive mb are s, d which are not corrupt. Since the adversary only receives messages that reach corrupt hosts, his view is identical for either value of b (i.e., for either message sent, see confidentiality experiment in Section 3.3.2). The adversary is blind, therefore he identifies whether m0 or m1 was sent with probability 21 , this is also the probability that the confidentiality requirement returns 1 (adversary outputs b) as required. 8.3. Availability

In this subsection we sketch the proof of the confidentiality requirement presented in Section 3.3.3. LOT does not change the number of hops that a message traverses from its source to the destination (since the tunnel is transparent). Thus, if a message sent at time t from source s arrives at a destination d, then it arrives at time t + δhops(s, d) at the latest. Let m be a message sent by s to d and let LOT(m) denote the encapsulated version of m. We calculate the probability m does not arrive at d. This happens if one of two events occur: (1) m or LOT(m) is lost on a link between s and d. (2) a LOT-gateway discards LOT(m). Since bounds the loss probability between two peers, the first event occurs with probability of at most 1 − (1 − )hops(s,d) . We compute the probability that the second event occurs and show that it is negligible. Let G be a LOT-gateway, G discards LOT(m) only in case that both the following hold: (1) there is a tunnel between NB(G) and a network block netblock, and s ∈ netblock. (2) LOT(m) does not specify a valid periodic tag (according to the tunnel). ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:26


By our construction of LOT, the above occurs if and only if the adversary has established the tunnel between netblock and NB(G). For any α-neighborhood adversary, the probability that the adversary completes the handshake with G is negligible in n, the number of iterations during the network block validation protocol (see analysis in Section 5.2). This argument is true for any of the hops(s, d) − 1 peer LOT-gateways that a message from s to d traverses. Therefore, there exists a negligible function negl such that the probability that any LOT-gateway discards LOT(m) before it reaches d is at most negl(n). The probability that a message sent from s does not arrive at d is at most 1 − (1 − )hops(s,d) + negl(n), as required. 9. RELATED WORKS

LOT is secured only against non eavesdropping adversaries; there are several works on preventing attackers from obtaining such abilities, many suggest mechanisms deployed on BGP routers including [Heffernan 1998; Kent et al. 2000; White 2003; Aiello et al. 2003; Karlin et al. 2006; Lad et al. 2006]. Our work is related to previous works on lightweight and opportunistic security protocols, including methods for tagging traffic and identifying spoofed packets. LOT is also related to methods for identifying and mitigating network level DoS attacks. 9.1. Opportunistic Tunnels

Two notable opportunistic protocols to establish IPsec tunnels were proposed: Opportunistic IKE and BTNS. Both use methods different from LOT to validate the remote peer. We briefly discuss both of these proposals below. Opportunistic IKE was proposed by the FreeS/WAN project [Gilmore 2003] and is documented in [Richardson and Redelmeier 2005; Richardson 2005]. The specification requires the network administrator to place a reverse DNS record that maps to the network’s gateway address and its public key. The initiator retrieves the DNS record and uses the fetched configuration to start the IKE negotiation. The opportunistic IKE proposal has several shortcomings. First, each connection initiation requires a reverse DNS query resolution which presents a significant overhead for connections with legacy systems, that do not implement [Richardson and Redelmeier 2005]; this may even be exploited as a DDoS vector. Second, deploying opportunistic IKE requires control over the reverse DNS server and additional management effort which is not always feasible (e.g., for home networks). The Better Than Nothing Security (BTNS) group proposed another solution to IPsec’s deployment problem, using a concept they call Leap of Faith. Namely, the BTNS protocol is an unauthenticated mode of IPsec [Williams and Richardson 2008; Touch et al. 2008], where the identity of the remote peer is never validated; however, it remains the same throughout the entire connection. This means that the protocol is vulnerable to MitM attacks upon the negotiation of the connection; but, once the handshake completes successfully, the connection is secure. The BTNS protocol is rather different from LOT. It is designed to be deployed at hosts, cf. to LOT which is gateway to gateway. Additionally, as opposed to LOT, BTNS is not designed to be resilient to DoS attacks due to increased computation, as recognized in [Touch et al. 2008]. Moreover, an attacker may form BTNS tunnels from ephemeral IP addresses (e.g., with DHCP) disrupting communication with a host that obtains the same IP address in the future. However, as long as the handshake completes successfully, BTNS uses cryptography (IPsec) to protect against a MitM attacker, while LOT only protects against spoofing adversaries. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.


A:27

9.2. Spoofed Traffic Filtering

LOT attaches a random identifier (tag) to packets to identify their source, this is much like IKE and TCP cookies [Kaufman 2005; Bernstein 1996], Stateless Internet Flow Filter (SIFF) [Yaar et al. 2004] and the φ-filtering mechanism [Badishi et al. 2007; Badishi et al. 2008]. However, LOT’s opportunistic and hop by hop mechanisms are innovative. IPsec [Kent and Seo 2005] can also be employed as a lightweight mechanism to prevent (just) IP spoofing by using randomly-chosen SPI values, and without encryption or message authentication. However, during the handshake phase using IPsec results in significantly more overhead than LOT. There are different approaches for identifying and discarding spoofed traffic. The first approach that we discuss is route based; SAVE [Li et al. 2002] and RBF [Park and Lee 2001] follow this approach and identify spoofed packets based on their incoming interface and previous hop (respectively). Another route-based mechanism is Hop-Count Filtering (HCF) [Wang et al. 2007], which identifies spoofed packets according to their TTL value. SAVE, RBF and HCF rely mainly on heuristics to identify illegitimate traffic; i.e., a router first observes and studies network traffic and then filters unwanted (spoofed) packets. In contrast to LOT, these mechanisms allow filtering only at the receiver’s end. Ingress and egress filtering [Killalea 2000] are usually deployed at ISPs to discard spoofed traffic based on physical interfaces as well. These mechanisms do not rely on heuristics, but are only effective against spoofed traffic that originates from the ISP’s own clients (ingress filtering), or traffic that arrives from the outside, but specifies a source address within the ISP’s network (egress filtering). LOT filters spoofed traffic that originates outside of a gateway’s network and specifies an arbitrary source address, but in contrast to the mechanisms above, LOT cooperates with the gateway of the specified source. LOT can be deployed together with other route based filters. The Spoofing Prevention Method (SPM) [Bremler-Barr and Levy 2005] relies on capabilities. A unique key is associated with each pair of source and destination networks, and each packet is tagged with the corresponding key. This allows receiving end gateways to verify the key and thereby the authenticity of a packet’s source address. This on the contrary to LOT which allows the first LOT router on the path to filter the spoofed packet. 9.3. Mitigation Techniques for Network Level Denial of Service

In this paper we proposed near source filtering techniques to mitigate DoS attacks, Argyraki et al. [Argyraki and Cheriton 2005b] suggest a technique of that type as well: their method uses the route record IP option [Postel 1981b] to identify and filter malicious flows by their source. This method is similar to packet marking techniques (e.g., [Snoeren 2001; Dean et al. 2002]) which where first considered in [Savage et al. 2000] and later improved [Song and Perrig 2001]. In these techniques, nodes along the route attach marks to traversing traffic. The marks allow the recipient to identify and filter malicious flows. However, these methods require deployment at core Internet routers and ISPs (c.f. to LOT); as a result, there has been much reluctance to deploy them. Bellovin proposed ICMP traceback [Bellovin 2003], a mechanism deployed on routers; the routers occasionally send an ICMP indication when forwarding a packet to its destination. This allows the recipient to infer on a packet’s route and filter traffic that appears to be spoofed. However, ICMP is prone to abuse and is therefore often blocked; furthermore, this mechanism requires deployment on Internet routers. These prevent widespread deployment of ICMP traceback. Capability based mechanisms [Yaar et al. 2004; Anderson et al. 2004; Bremler-Barr and Levy 2005; Yang et al. 2008] only allow sources that obtained capabilities for a ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:28


specific destination to send data to it. Such approaches are subjected to DoS attacks as pointed out in [Argyraki and Cheriton 2005a]. Namely, the attacker floods the recipient with capability-request messages, thereby exhausting the control channel; hence preventing legitimate senders from obtaining capabilities. Furthermore, these do not prevent authorized, but malicious, hosts from passing massive amounts of traffic between them. Such attacks where considered in [Sherwood et al. 2005; Studer and Perrig 2009]; these attacks congest a link on the route between malicious entities with ‘legitimate’ traffic, denying others from using that link. LOT addresses these issues as its opportunistic approach implies that tunneling is not mandatory for sending data; furthermore, LOT employs mechanisms to detect and mitigate congestions along the route. LOT allows filtering of malicious traffic near its source (see Section 6.1), this approach was previously suggested by [Ioannidis and Bellovin 2002; Huici and Handley 2007; Wang et al. 2007]. We briefly discuss these suggestions bellow: Ioannidis et al. [Ioannidis and Bellovin 2002] propose a ‘push back’ methodology where routers detect and discard malicious packets by heuristics. Then, the routers notify upstream routers to do the same (hence ‘push back’), allowing legitimate traffic to pass through the congest link. In LOT, which works hop by hop, the first router that encounters a spoofed packet, is able to identify and filter it. Furthermore, LOT employs mechanisms that allow upstream gateways to identify congestions on their own, and does not require deployment on core Internet routers. A scheme presented in [Huici and Handley 2007] suggests an IP-in-IP tunneling mechanism deployed at the ISP level. Packets from one ISP to the other are encapsulated, the new IP header specifies the decapsulator at the receiving ISP as the new destination. When an attack is identified at the receiving end, the decapsulator sends a filter request to the corresponding source of the tunnel (encapsulator). LOT tunnels are unique in the sense that they are transparent; i.e., do not change the source and destination addresses (and network routing) in order to filter unwanted traffic. PATRICIA [Wang et al. 2007] is a cooperative mechanism where participating ASs share information about suspected malicious traffic, this allows filtering of such traffic near its source. The latter two suggestions ([Wang et al. 2007; Huici and Handley 2007]) are not opportunistic (cf. to LOT), relations between cooperative parties (ISPs or ASs) must be set up in advance. Furthermore, these suggestions require significant changes to deploying nodes: [Huici and Handley 2007] requires deployment at ISPs and [Wang et al. 2007] requires traffic regulators in ASs, deployment at BGP routers, and tunnel aware end hosts. LOT is designed to be effective even when deployed only on edge gateways. 10. CONCLUSIONS AND FUTURE WORK

Despite substantial efforts to mitigate IP spoofing, it is still a significant threat; many ISPs do not enforce ingress filtering, and many clients are still able to conduct it. We showed that this problem can be solved efficiently, only requiring changes to edge networks and not at the ISP or core Internet routers level; once the source of a packet is authenticated, different mechanisms can be employed to effectively mitigate DoS attacks. We believe that our results show the potential of opportunistic mechanisms in improving security against realistic attackers. Many questions and challenges remain for future research, including: Traffic quotas. We suggested the use of per flow quotas to mitigate DoS attacks. In our experiments we used specific parameters to define a per flow leaky bucket arrival ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.


A:29

curve. While we showed this method effective, further analysis is required as to how to define optimal parameters and change them dynamically with consideration of the current incoming traffic. Near source quotas/filtering analysis. Analysis needs to be made as to the overhead of near source mechanisms. Specifically, do they result in significant overhead on the sender’s gateway? should receiving-end gateways enforce these as well, or does relaying on negative feedbacks (e.g., by the sender’s gateway) perform better? Congestion countermeasures. We showed how two LOT gateways can detect a congestion on the route between them. In our simulations, once detected, sending gateways discard packets probabilistically until congestion is relieved. However, this is only a basic mechanism; further research is required as to the appropriate countermeasure. Hardware implementation. We made efforts for LOT to be simple and efficient. However, we only provide a software implementation. Can it be efficiently implemented in hardware to allow deployment on routers? Integration with existing firewalls. We consider our implementation a prototype, it would be very desirable to integrate LOT into an existing firewall product. A. IMPLEMENTATION DETAILS A.1. Challenge Messages

During the network block validation phase, destination addresses and challenges are derived using the function described in Algorithm 1. The algorithm uses a pseudorandom function (PRF), this may be implemented with a block cipher, e.g., AES. The variable netblock.d is the direction flag (see Section 4), its value is either ‘in’ or ‘out’. If netblock.d = ‘out’, then the remote gateway specifies that it controls all addresses outside netblock. The challenge Algorithm 1 creates is λ bits long, in practice we believe that λ = 32 will suffice. The function described in Algorithm 1 is for network blocks of IPv4 addresses, adaptations for IPv6 are described in Section A.1.1. A.1.1. Adaptations for IPv6. In the modified version of Algorithm 1 the first 64 bits are used to choose an arbitrary unicast global routing prefix and a subnet identifier for the destination (see the IPv6 address structure [Hinden and Deering 2006]). The bottom 64 bits of a 128-bit IPv6 address are the recipient’s interface identifier. Since this part of the address is used only at the destination and LOT challenges are intercepted by the network gateway (before reaching the host), any constant valid value would suffice. The following λ bits of the PRF output are used to create the challenge (as in the IPv4 version of Algorithm 1). A.2. LOT Header

In addition to the periodic tag (see Section 7.2), the LOT header includes the following: Protocol. The protocol field saves the IP protocol field of the original packet. This value is used to restore the original field on decapsulation. Flags. A single byte flags field, which specifies 5 flags:

— DF and MF flags: two bits save the original values of the DF and MF flags, from the IP header of the original packet. — CM: specifies whether the packet is a control message. Control messages are used to start and stop encapsulation, tear down and re-validate the tunnel. ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:30


Fk (netblock, time, i, n) : if netblock.d equals ‘in’ then ϕ ← PRFk (netblock||time||i||n); DestIP ← netblock.base-address + ϕ[0...(31 − netblock.l)]; end else if netblock.l equals 0 then return Error; end round ← 0 repeat ϕ ← PRFk (netblock||time||i||n||round); DestIP ← ϕ[0...31]; round ← round + 1; S S until DestIP not in {netblock local-netblock Martian addresses}; end Challenge ← ϕ[32..32 + (λ − 1)]; return DestIP, Challenge; Algorithm 1: Pseudo-randomly creates a challenge for the network block validation phase. The function receives as arguments the network block description (see Section 4), the time that the network block validation has began, the iteration number i, and the total number of iterations n. — TP: the tag parity (TP) flag allows the receiver to identify whether the current or the previous tag was used to encapsulate the packet (for smooth transition between tags). — SL: the stateless flag specifies whether the packet can be authenticated without keeping state. If lit, the time and n parameters used for creating the challenges during the handshake (see Section 5 and Algorithm 1) are also specified in the LOT header. These allow the authenticator to rebuild the last cookie (used as session key) and recreate the current periodic tag. This is similar to the approach taken in the network block validation phase described in Section 5. Time, n. Optional fields; see description of the SL flag. ACKNOWLEDGMENTS Thanks to Amit Klein, Yaron Sheffer and the anonymous referees for their comments and suggestions, to Ahren Studer and Adrian Perrig for giving us their simulator code for the Coremelt attack. Special thanks to Yehoshua Gev for helping test LOT with the Coremelt attack and solve technical problems.

REFERENCES A DVANCED N ETWORK A RCHITECTURE G ROUP. 2011. ANA Spoofer Project. http://spoofer.csail.mit. edu/index.php. A HARONI , M. AND H IDALGO, W. M. 2005. Cisco SNMP Configuration Attack With a GRE Tunnel. Article in Security Focus site, http://www.securityfocus.com/infocus/1847. A IELLO, I OANNIDIS, AND M C D ANIEL. 2003. Origin Authentication in Interdomain Routing. In SIGSAC: 10th ACM Conference on Computer and Communications Security. ACM Press, 165–178. A NDERSON, T. E., R OSCOE , T., AND W ETHERALL , D. 2004. Preventing Internet Denial-of-Service with Capabilities. Computer Communication Review 34, 1, 39–44. A RGYRAKI , K. AND C HERITON, D. 2005a. Network Capabilities: The Good, the Bad and the Ugly. In Fourth Workshop on Hot Topics in Networks.



A:31

A RGYRAKI , K. J. AND C HERITON, D. R. 2005b. Active Internet Traffic Filtering: Real-Time Response to Denial-of-Service Attacks. In USENIX Annual Technical Conference, General Track. USENIX, 135–148. B ADISHI , G., H ERZBERG, A., AND K EIDAR , I. 2007. Keeping Denial-of-Service Attackers in the Dark. IEEE Transactions on Dependable and Secure Computing 4, 3, 191–204. B ADISHI , G., H ERZBERG, A., K EIDAR , I., R OMANOV, O., AND YACHIN, A. 2008. An Empirical Study of Denial of Service Mitigation Techniques. In IEEE Symposium on Reliable Distributed Systems. IEEE Computer Society, Los Alamitos, CA, USA, 115–124. B AKER , F. AND S AVOLA , P. 2004. Ingress Filtering for Multihomed Networks. RFC 3704 (Best Current Practice). B ELLOVIN, S. 2003. ICMP Traceback Messages. http://tools.ietf.org/html/draft-ietf-itrace-04. B ERNSTEIN, D. 1996. TCP SYN cookies. Published in Bernstein’s website, http://cr.yp.to/syncookies. html. B EVERLY, R. AND B AUER , S. 2005. The Spoofer Project: Inferring the Extent of Source Address Filtering on the Internet. In Steps to Reducing Unwanted Traffic on the Internet Workshop SRUTI’05. USENIX Association Berkeley, CA, USA. B REMLER -B ARR , A. AND L EVY, H. 2005. Spoofing Prevention Method. In INFOCOM. IEEE, 536–547. C HANG, R. 2002. Defending Against Flooding-Based Distributed Denial-of-Service Attacks: A Tutorial. IEEE Communications Magazine 40, 42–51. C ISCO S YSTEMS. 2007. Pre-Fragmentation for IPsec VPNs. http://www.ciscosystems.cd/en/US/docs/ ios/sec_secure_connectivity/configuration/guide/sec_pre_frag_vpns.pdf. D AEMEN, J. AND R IJMEN, V. 2002. The Design of Rijndael: AES–the Advanced Encryption Standard. Springer Verlag. D EAN, D., F RANKLIN, M., AND S TUBBLEFIELD, A. 2002. An Algebraic Approach to IP Traceback. ACM Transactions on Information and System Security 5, 2, 119–137. D OMMETY, G. 2000. Key and Sequence Number Extensions to GRE. RFC 2890 (Proposed Standard). E DDY, W. 2007. TCP SYN Flooding Attacks and Common Mitigations. RFC 4987 (Informational). FARINACCI , D., L I , T., H ANKS, S., M EYER , D., AND T RAINA , P. 2000. Generic Routing Encapsulation (GRE). RFC 2784 (Proposed Standard). Updated by RFC 2890. F ERGUSON, P. AND S ENIE , D. 2000. Network Ingress Filtering: Defeating Denial of Service Attacks which Employ IP Source Address Spoofing. RFC 2827 (Best Current Practice 38). Updated by RFC 3704. G ILAD, Y. AND H ERZBERG, A. 2009. Lightweight Opportunistic Tunneling (LOT). In ESORICS, M. Backes and P. Ning, Eds. Lecture Notes in Computer Science Series, vol. 5789. Springer, 104–119. G ILAD, Y. AND H ERZBERG, A. 2011. Fragmentation Considered Vulnerable: Blindly Intercepting and Discarding Fragments. In Proceedings of the 2011 USENIX Workshop on Offensive Technologies. G ILMORE , J. 2003. FreeS/WAN Project. www.freeswan.org. G OLDREICH , O. 2001. Foundations of Cryptography. Vol. 1: Basic Tools. Cambridge University Press. H ARRIS, B. AND H UNT, R. 1999. TCP/IP Security Threats and Attack Methods. Computer Communications 22, 885–897. H EFFERNAN, A. 1998. Protection of BGP Sessions via the TCP MD5 Signature Option. RFC 2385 (Proposed Standard). H EFFNER , J., M ATHIS, M., AND C HANDLER , B. 2007. IPv4 Reassembly Errors at High Data Rates. RFC 4963 (Informational). H INDEN, R. AND D EERING, S. 2006. IP Version 6 Addressing Architecture. RFC 4291 (Draft Standard). H OFFMAN, P. 2005. Cryptographic Suites for IPsec. RFC 4308 (Proposed Standard). H UICI , F. AND H ANDLEY, M. 2007. An Edge-to-Edge Filtering Architecture Against DoS. Computer Communication Review 37, 2, 39–50. IANA. 2002. Special-Use IPv4 Addresses. RFC 3330 (Informational). I OANNIDIS, J. AND B ELLOVIN, S. M. 2002. Implementing Pushback: Router-Based Defense Against DDoS Attacks. In NDSS. The Internet Society. J IANG, G. 2002. Multiple Vulnerabilities in SNMP. Computer 35, 4, 2–4. K AMINSKY, D. 2008. It’s The End Of The Cache As We Know It. In Black Hat conference. http://www. doxpara.com/DMK_BO2K8.ppt. K ARLIN, J., F ORREST, S., AND R EXFORD, J. 2006. Pretty Good BGP: Improving BGP by Cautiously Adopting Routes. In ICNP: IEEE International Conference on Network Protocols. IEEE Computer Society, 290– 299.


A:32


K AUFMAN, C. 2005. Internet Key Exchange (IKEv2) Protocol. RFC 4306 (Proposed Standard). Updated by RFC 5282. K AUFMAN, C., P ERLMAN, R. J., AND S OMMERFELD, B. 2003. DoS Protection for UDP-Based Protocols. In Proceedings of the 10th ACM Conference on Computer and Communications Security, CCS 2003, Washington, DC, USA, S. Jajodia, V. Atluri, and T. Jaeger, Eds. ACM, 2–7. K ENT, C. A. AND M OGUL , J. C. 1987. Fragmentation Considered Harmful. Research Report 87/3, Western Research Lab. Dec. An abbreviated version was published in the proceedings of the ACM SIGCOMM, 390–401, 1987. K ENT, S., LYNN, C., AND S EO, K. 2000. Secure Border Gateway Protocol (S-BGP). IEEE Journal on Selected Areas in Communications 18, 4, 582–592. K ENT, S. AND S EO, K. 2005. Security Architecture for the Internet Protocol. RFC 4301 (Proposed Standard). K ILLALEA , T. 2000. Recommended Internet Service Provider Security Services and Procedures. RFC 3013 (Best Current Practice). K LEIN, A. 2007. BIND 9 DNS Cache Poisoning. Report, Trusteer, Ltd. L AD, M., M ASSEY, D., P EI , D., W U, Y., Z HANG, B., AND Z HANG, L. 2006. PHAS: a Prefix Hijack Alert System. In Proceedings of the 15th conference on USENIX Security Symposium. USENIX Association. L AKSHMINARAYANAN, K., A DKINS, D., P ERRIG, A., AND S TOICA , I. 2004. Taming IP Packet Flooding Attacks. Computer Communication Review 34, 1, 45–50. L EMON, J. 2002. Resisting SYN Flood DoS Attacks with a SYN Cache. In BSDCon, S. J. Leffler, Ed. USENIX, 89–97. L I , J., M IRKOVIC, J., WANG, M., R EIHER , P. L., AND Z HANG, L. 2002. SAVE: Source Address Validity Enforcement Protocol. In Proceedings of the 21st Annual Joint Conference of the IEEE Computer and Communications Society (INFOCOM-02). IEEE Computer Society, Piscataway, NJ, USA, 1557–1566. M OGUL , J. AND D EERING, S. 1990. Path MTU Discovery. RFC 1191 (Draft Standard). M OORE , D., V OELKER , G., AND S AVAGE , S. 2001. Inferring Internet Denial of Service Activity. In Proceedings of the 10th USENIX Security Symposium. USENIX, Washington, D.C. PANG, R., Y EGNESWARAN, V., B ARFORD, P., PAXSON, V., AND P ETERSON, L. 2004. Characteristics of Internet Background Radiation. In Proceedings of the 4th ACM SIGCOMM Conference on Internet Measurement. ACM New York, NY, USA, 27–40. PARK , K. AND L EE , H. 2001. On the Effectiveness of Route-Based Packet Filtering for Distributed DoS Attack Prevention in Power-Law Internets. In SIGCOMM. 15–26. PAXSON, V. 2001. An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks. Computer Communication Review 31, 3, 38–47. P ENG, T., L ECKIE , C., AND R AMAMOHANARAO, K. 2007. Survey of Network-based Defense Mechanisms Countering the DoS and DDoS Problems. ACM Computing Surveys 39, 1, 3:1–3:42. P OSTEL , J. 1981a. Internet Control Message Protocol. RFC 792 (Standard). Updated by RFCs 950, 4884. P OSTEL , J. 1981b. Internet Protocol. RFC 791 (Standard). Updated by RFC 1349. R ICHARDSON, M. 2005. A Method for Storing IPsec Keying Material in DNS. RFC 4025 (Proposed Standard). R ICHARDSON, M. AND R EDELMEIER , D. 2005. Opportunistic Encryption using the Internet Key Exchange (IKE). RFC 4322 (Informational). S AVAGE , S., W ETHERALL , D., K ARLIN, A. R., AND A NDERSON, T. E. 2000. Practical Network Support for IP Traceback. In SIGCOMM. 295–306. S HERWOOD, R., B HATTACHARJEE , B., AND B RAUD, R. 2005. Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse. In Proceedings of the 12th ACM Conference on Computer and Communications Security, CCS 2005, Alexandria, VA, USA, November 7-11, 2005, V. Atluri, C. Meadows, and A. Juels, Eds. ACM, 383–392. S NOEREN, A. C. 2001. Hash-Based IP Traceback. In SIGCOMM. 3–14. S ONG, D. X. AND P ERRIG, A. 2001. Advanced and Authenticated Marking Schemes for IP Traceback. In INFOCOM. 878–886. S RISURESH , P. AND E GEVANG, K. 2001. Traditional IP Network Address Translator (Traditional NAT). RFC 3022 (Informational). S TUDER , A. AND P ERRIG, A. 2009. The Coremelt Attack. In ESORICS, M. Backes and P. Ning, Eds. Lecture Notes in Computer Science Series, vol. 5789. Springer, 37–52. T OUCH , J., B LACK , D., AND WANG, Y. 2008. Problem and Applicability Statement for Better-Than-Nothing Security (BTNS). RFC 5387 (Informational).



A:33

WANG, H., J IN, C., AND S HIN, K. G. 2007. Defense Against Spoofed IP Traffic Using Hop-Count Filtering. IEEE/ACM Transactions on Networking 15, 1, 40–53. WANG, L., W U, Q., AND L UONG, D. 2007. Engaging Edge Networks in Preventing and Mitigating Undesirable Network Traffic. In Proceedings of the 2007 3rd IEEE Workshop on Secure Network Protocols. IEEE Computer Society, 1–6. W HITE , R. 2003. Securing BGP Through Secure Origin BGP. The Internet Protocol Journal 6, 15–22. W ILLIAMS, N. AND R ICHARDSON, M. 2008. Better-Than-Nothing Security: An Unauthenticated Mode of IPsec. RFC 5386 (Proposed Standard). YAAR , A., P ERRIG, A., AND S ONG, D. X. 2004. SIFF: A Stateless Internet Flow Filter to Mitigate DDoS Flooding Attacks. In IEEE Symposium on Security and Privacy. IEEE Computer Society, 130–143. YANG, X., W ETHERALL , D., AND A NDERSON, T. E. 2008. TVA: a DoS-Limiting Network Architecture. IEEE/ACM Transactions on Networking 16, 6, 1267–1280.
