Results 1 - 10
of
91
A DoS-limiting network architecture
- In Proceedings of ACM SIGCOMM
, 2005
"... We present the design and evaluation of TVA, a network architecture that limits the impact of Denial of Service (DoS) floods from the outset. Our work builds on earlier work on capabilities in which senders obtain short-term authorizations from receivers that they stamp on their packets. We address ..."
Abstract
-
Cited by 191 (6 self)
- Add to MetaCart
(Show Context)
We present the design and evaluation of TVA, a network architecture that limits the impact of Denial of Service (DoS) floods from the outset. Our work builds on earlier work on capabilities in which senders obtain short-term authorizations from receivers that they stamp on their packets. We address the full range of possible attacks against communication between pairs of hosts, including spoofed packet floods, network and host bottlenecks, and router state exhaustion. We use simulation to show that attack traffic can only degrade legitimate traffic to a limited extent, significantly outperforming previously proposed DoS solutions. We use a modified Linux kernel implementation to argue that our design can run on gigabit links using only inexpensive off-the-shelf hardware. Our design is also suitable for transition into practice, providing incremental benefit for incremental deployment.
An End-Middle-End Approach to Connection Establishment
- IN: PROCEEDINGS OF SIGCOMM’07, KYOTO
, 2007
"... We argue that the current model for flow establishment in the Internet: DNS Names, IP addresses, and transport ports, is inadequate due to problems that go beyond the small IPv4 address space and resulting NAT boxes. Even where global addresses exist, firewalls cannot glean enough information about ..."
Abstract
-
Cited by 44 (1 self)
- Add to MetaCart
We argue that the current model for flow establishment in the Internet: DNS Names, IP addresses, and transport ports, is inadequate due to problems that go beyond the small IPv4 address space and resulting NAT boxes. Even where global addresses exist, firewalls cannot glean enough information about a flow from packet headers, and so often err, typically by being over-conservative: disallowing flows that might otherwise be allowed. This paper presents a novel architecture, protocol design, and implementation, for flow establishment in the Internet. The architecture, called NUTSS, takes into account the combined policies of endpoints and network providers. While NUTSS borrows liberally from other proposals (URI-like naming, signaling to manage ephemeral IPv4 or IPv6 data flows), NUTSS is unique in that it couples overlay signaling with data-path signaling. NUTSS requires no changes to existing network protocols, and combined with recent NAT traversal techniques, works with IPv4 and existing NAT/firewalls. This paper describes NUTSS and shows how it satisfies a wide range of “end-middle-end” network requirements, including access control, middlebox steering, multi-homing, mobility, and protocol negotiation.
Routing as a Service
, 2004
"... Many recent proposals have argued for giving end-hosts control over routing in the network to satisfy the growing demands of applications. However, these proposals either run at an overlay level independent of one another, or else lack support for end-hosts to discover the desired routes. In this pa ..."
Abstract
-
Cited by 44 (6 self)
- Add to MetaCart
Many recent proposals have argued for giving end-hosts control over routing in the network to satisfy the growing demands of applications. However, these proposals either run at an overlay level independent of one another, or else lack support for end-hosts to discover the desired routes. In this paper, we propose a network architecture that addresses these limitations. At the basis of our solution lies the idea that specialized route computation should be provided as a service and not embedded in the infrastructure. This design allows the routing functionality to evolve without changing the infrastructure. Our architecture consists of three entities: (a) a forwarding infrastructure that enables end-hosts to setup routes, (b) Routing Service (ROSE) providers that compute routes (conforming to application requirements) based on network information that the infrastructure provides, and (c) end-hosts that setup the routes, obtained by querying ROSE, in the infrastructure. We address the issues of trust, scalability of the ROSE architecture, and deployability. We demonstrate the feasibility of our solution by conducting experiments on a prototype deployed on PlanetLab. To illustrate the benefits of our architecture we evaluate two applications: metric-sensitive multicast, and resilient routing.
DDoS-resilient scheduling to counter application layer attacks under imperfect detection
- IN PROCEEDINGS OF IEEE INFOCOM
, 2006
"... ... attacks is becoming ever more challenging with the vast resources and techniques increasingly available to attackers. In this paper, we consider sophisticated attacks that are protocol-compliant, non-intrusive, and utilize legitimate application-layer requests to overwhelm system resources. We c ..."
Abstract
-
Cited by 43 (1 self)
- Add to MetaCart
... attacks is becoming ever more challenging with the vast resources and techniques increasingly available to attackers. In this paper, we consider sophisticated attacks that are protocol-compliant, non-intrusive, and utilize legitimate application-layer requests to overwhelm system resources. We characterize applicationlayer resource attacks as either request flooding, asymmetric, or repeated one-shot, on the basis of the application workload parameters that they exploit. To protect servers from these attacks, we propose a counter-mechanism that consists of a suspicion assignment mechanism and a DDoS-resilient scheduler, DDoS Shield. In contrast to prior work, our suspicion mechanism assigns a continuous value as opposed to a binary measure to each client session, and the scheduler utilizes these values to determine if and when to schedule a session’s requests. Using testbed experiments on a web application, we demonstrate the potency of these resource attacks and evaluate the efficacy of our countermechanism. For instance, we mount an asymmetric attack which overwhelms the server resources, increasing the response time of legitimate clients from 0.1 seconds to 40 seconds. Under the same attack scenario, DDoS Shield improves the victims’ performance to 1.5 seconds.
Passport: Secure and Adoptable Source Authentication
"... We present the design and evaluation of Passport, a system that allows source addresses to be validated within the network. Passport uses efficient, symmetric-key cryptography to place tokens on packets that allow each autonomous system (AS) along the network path to independently verify that a sour ..."
Abstract
-
Cited by 42 (6 self)
- Add to MetaCart
(Show Context)
We present the design and evaluation of Passport, a system that allows source addresses to be validated within the network. Passport uses efficient, symmetric-key cryptography to place tokens on packets that allow each autonomous system (AS) along the network path to independently verify that a source address is valid. It leverages the routing system to efficiently distribute the symmetric keys used for verification, and is incrementally deployable without upgrading hosts. We have implemented Passport with Click and XORP and evaluated the design via micro-benchmarking, experiments on the Deterlab, security analysis, and adoptability modeling. We find that Passport is plausible for gigabit links, and can mitigate reflector attacks even without separate denial-of-service defenses. Our adoptability modeling shows that Passport provides stronger security and deployment incentives than alternatives such as ingress filtering. This is because the ISPs that adopt it protect their own addresses from being spoofed at each other’s networks even when the overall deployment is small. 1.
Accountable Internet Protocol (AIP)
"... This paper presents AIP (Accountable Internet Protocol), a network architecture that provides accountability as a first-order property. AIP uses a hierarchy of self-certifying addresses, in which each component is derived from the public key of the corresponding entity. We discuss how AIP enables si ..."
Abstract
-
Cited by 40 (1 self)
- Add to MetaCart
(Show Context)
This paper presents AIP (Accountable Internet Protocol), a network architecture that provides accountability as a first-order property. AIP uses a hierarchy of self-certifying addresses, in which each component is derived from the public key of the corresponding entity. We discuss how AIP enables simple solutions to source spoofing, denial-of-service, route hijacking, and route forgery. We also discuss how AIP’s design meets the challenges of scaling, key management, and traffic engineering. Categories and Subject Descriptors C.2.6 [Internetworking]; C.2.1 [Computer-Communication
HTTP as the NarrowWaist of the Future Internet
, 2010
"... Over the past decade a variety of network architectures have been proposed to address IP’s limitations in terms of flexible forwarding, security, and data distribution. Meanwhile, fueled by the explosive growth of video traffic and HTTP infrastructure (e.g., CDNs, web caches), HTTP has became the de ..."
Abstract
-
Cited by 40 (3 self)
- Add to MetaCart
(Show Context)
Over the past decade a variety of network architectures have been proposed to address IP’s limitations in terms of flexible forwarding, security, and data distribution. Meanwhile, fueled by the explosive growth of video traffic and HTTP infrastructure (e.g., CDNs, web caches), HTTP has became the de-facto protocol for deploying new services and applications. Given these developments, we argue that these architectures should be evaluated not only with respect to IP, but also with respect to HTTP, and that HTTP could be a fertile ground (more so than IP) for deploying the newly proposed functionalities. In this paper, we take a step in this direction, and find that HTTP already provides many of the desired properties for new Internet architectures. HTTP is a content centric protocol, provides middlebox support in the form of reverse and forward proxies, and leverages DNS to decouple names from addresses. We then investigate HTTP’s limitations, and propose an extension, called S-GET that provides support for low-latency applications, such as VoIP and chat. 1.
TVA: a DoS-limiting Network Architecture
"... We motivate the capability approach to network denial-of-service (DoS) attacks, and evaluate the TVA architecture which builds on capabilities. With our approach, rather than send packets to any destination at any time, senders must first obtain “permission to send” from the receiver, which provides ..."
Abstract
-
Cited by 36 (5 self)
- Add to MetaCart
(Show Context)
We motivate the capability approach to network denial-of-service (DoS) attacks, and evaluate the TVA architecture which builds on capabilities. With our approach, rather than send packets to any destination at any time, senders must first obtain “permission to send” from the receiver, which provides the permission in the form of capabilities to those senders whose traffic it agrees to accept. The senders then include these capabilities in packets. This enables verification points distributed around the network to check that traffic has been authorized by the receiver and the path in between, and hence to cleanly discard unauthorized traffic. To evaluate this approach, and to understand the detailed operation of capabilities, we developed a network architecture called TVA. TVA addresses a wide range of possible attacks against communication between pairs of hosts, including spoofed packet floods, network and host bottlenecks, and router state exhaustion. We use simulations to show the effectiveness of TVA at limiting DoS floods, and an implementation on Click router to evaluate the computational costs of TVA. We also discuss how to incrementally deploy TVA into practice.
Revisiting IP Multicast
, 2006
"... This paper revisits a much explored topic in networking – the search for a simple yet fully-general multicast design. The many years of research into multicast routing have led to a generally pessimistic view that the complexity of multicast routing – and inter-domain multicast routing in particular ..."
Abstract
-
Cited by 33 (2 self)
- Add to MetaCart
(Show Context)
This paper revisits a much explored topic in networking – the search for a simple yet fully-general multicast design. The many years of research into multicast routing have led to a generally pessimistic view that the complexity of multicast routing – and inter-domain multicast routing in particular – can only be overcome by restricting the service model (as in single-source) multicast. This paper proposes a new approach to implementing IP multicast that we hope leads to a reevaluation of this commonly held view.