Oliver Spatscheck and Larry L. Peterson. Defending against denial of service attacks in Scout. In Proc. 3rd OSDI, pages 59--72, Feb 1999.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....A. Resource control in multimedia systems Resource control has been central question in multimedia systems research for at least the past 10 years or so. Control of resources within a machine is now relatively well understood: it has been addressed in completely new operating systems (e.g. 1] [2]) modifications to existing operating systems (e.g. 3] schedulers ( 4] and abstractions ( 5] Many of these advances were motivated by the desire to handle multimedia and other time sensitive applications. Such mechanisms clearly have a place in a public computing platform designed to ....

O. Spatscheck and L. L. Peterson, "Defending Against Denial of Service Attacks in Scout," in Proceedings of the Third USENIX Symposium on Operating Systems Design and Implementation, February 1999.

....Access Control isolating data streams into a single address space, and isolates the effect of other applications by making scheduling decisions at each resource multiplexing point implementing an equivalent service to resource reservation in our model. Similarly, the Scout operating system[12, 15] introduces a path abstraction representing an I O channel. The paths are then schedulable and enforceable entities in Scout. This abstraction is similar to the notion of resource principal. Both Nemesis and Scout are operating systems built from scratch to efficiently account and enforce resource ....

O. Spatscheck and L. Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, Feb. 1999.

....avoided these problems by enhancing the kernel with a powerful policy for metadata management. In the Scout system, it is possible to limit the amount of kernel resources used by a particular I O path [40] which has been demonstrated to be an effective defense against denial of service attacks [49]. The Resource Container abstraction provides systems with a method to account kernel resources towards individual activities, and to impose limits on their resource usage [3] Other operating systems have provided means to dynamically customize or replace the management policy. SPIN uses a ....

....I O, while the rest is subjected to the normal paging scheme and can be paged out to backing store. Thus, the size of the metadata used by the kernel can exceed the amount of physical memory. Several other approaches introduce a new abstraction for resource principals. The Scout operating system [40, 49] supports a special path abstraction that represents a stream of data flowing through several subsystems, e.g. packets of a certain TCP connection. Resource Containers [3] can be used to account resource consumption towards individual activities; for example, a single thread can serve requests ....

[Article contains additional citation context not shown here]

Oliver Spatscheck and Larry L. Peterson. Defending against denial of service attacks in Scout. In Proceedings of the third symposium on Operating systems design and implementation, pages 59--72. USENIX Association, Feb 1999.

....intended for cluster based systems. Since communication costs are much higher in cluster based systems than in multiprocessor systems, there may be a mismatch in the granularity of dispatching work. In addition, this work does not address the impact of RC on system scalability. The Scout system [5] provides a di erent method of resource accounting. Scout identi es resource usage based on path and protection domains. A path is a logical entity that abstracts an I O channel, such as from the Ethernet layer to the TCP IP layer to the le system layer. Protection domains provide the ....

O. Spatscheck and L. Peterson. Defending against denial of service attacks in scout. In Proceedings 3rd USENIX Symposium on Operating Systems Design and Implementation, pages 45-48, New Orleans, Louisiana, February 1999.

....support, but also coordination among different routers and wide spread deployment. The end system approach protects Internet servers with sophisticated resource management to servers. This approach provides more accurate resource accounting, and fine grained service isolation and differentiation [1, 3, 32, 37], for example, to shield interactive video traffic from FTP traffic. However, without a mechanism to detect spoofed traffic, spoofed packets will share the same resource principals and code paths as legitimate requests. While a resource manager can confine the scope of damage to the particular ....

O. Spatscheck and L. Peterson. Defending against denial of service attacks in Scout. In Proceedings of USENIX OSDI'99, New Orleans, LA, February 1999.

....the a key goal of resource management. Numerous approaches have been proposed and implemented to achieve this goal [1, 2, 3, 9, 19, 25, 30, 36, 37] in which adaptation and hierarchy are the two key features. Also, resource isolation has been utilized as a powerful mechanism to counter DoS attacks [3, 17, 27]. However, most of these approaches are designed for applications, end hosts and edge routers, without paying attention to the resource management at core routers due mainly to the scalability problem. In this paper, based on the layer 4 classification, we build a flexible and scalable resource ....

O. Spatscheck and L. Peterson, "Defending Against Denial of Service Attacks in Scout", 3th Symposium on Operating System Design and Implementation, New Orleans, LA, February 1999.

....This requires a modification of the component source code, whereas in Think, binding factories can make security checks, and the binary code of the component is modified by the software based memory isolation mechanism without needing any modification of the component source code. The Scout Escort [9] project focuses on protection against denial of service attacks by defining the I O path abstraction. However, this does not take into account the resources allocated in the operating system kernel, whereas in Think, we aim toward a global view of the resources which enable the system to ....

Olivier Spatscheck, Larry L. Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 3rd USENIX Symposium on Operating Systems Design and Implementation, 1999.

....This requires a modification of the component source code, whereas in Think, binding factories can make security checks, and the binary code of the component is modified by the software based memory isolation mechanism without needing any modification of the component source code. The Scout Escort [8] project focuses on protection against denial of service attacks by defining the I O path abstraction. However, this does not take into account the resources allocated in the operating system kernel, whereas in Think, we aim toward a global view of the resources which enable the system to ....

Olivier Spatscheck, Larry L. Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 3rd USENIX Symposium on Operating Systems Design and Implementation, 1999.

....security is enforced by way of security servers, which check that intercomponent calls are allowed. This requires a modification of the component code, whereas in THINK, binding factories can make the security checks, which ensures a complete independence of the component code. The Scout Escort [6] project focuses on protection against denial of service attacks by defining the I O path abstraction. However, this does not take into account the resources allocated in the operating system kernel, whereas in THINK, we aim toward a global view of the resources which enable the system to ....

Olivier Spatscheck, Larry L. Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 3rd USENIX Symposium on Operating Systems Design and Implementation, 1999.

....used to queue messages on a domain s channels are allocated from (and charged to) the domain s memory pool. In other words, one can think of a domain as encapsulating resources used across both the NodeOS and an EE on behalf of a packet flow, similar to resource containers [2] and Scout paths [13]. A domain is not strictly a user level entity like a Unix process. A given domain is created in the context of an existing domain, making it natural to organize domains in a hierarchy, with the root domain corresponding to the NodeOS itself. Figure 2 shows a representative domain hierarchy, ....

Oliver Spatscheck and Larry Peterson. Defending against denial of service attacks in Scout. In Proceedings of the 3rd Symp. on Operating System Design and Impl., pages 59--72, February 1999.

....solutions, and middleware solutions. Our solution roughly falls in the network centric solution category although it is fully transparent to the end server. Operating System based solutions are usually invasive and require a lot of support from the operating system. The SCOUT operating system [8] is an example. Such OS level support includes, but is not limited to, keeping an account of network packets as they move through various layers of the OS. The Scout OS introduces a path abstraction to demarcate clearly the resources consumed by an I O path. As soon as a network packet enters the ....

Oliver Spatscheck and Larry L. Petersen, \Defending Against Denial of Service Attacks in Scout," in Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI'99), New Orleans, Louisiana, Feb. 1999, Available online at http://www.cs.arizona.edu/scout/Papers/osdi99.ps.

....systems based solutions, network centric solutions, and middleware solutions. Our solution roughly falls in the network centric solution category although it is fully transparent to the end server. Operating System based solutions are usually require a lot of support from the operating system [8]. Such OS level support includes, but is not limited to, keeping an account of network packets as they move through various layers of the OS. The Scout OS [8] introduces a path abstraction to demarcate clearly the resources consumed by an I O path. As soon as a network packet enters the OS, it is ....

....it is fully transparent to the end server. Operating System based solutions are usually require a lot of support from the operating system [8] Such OS level support includes, but is not limited to, keeping an account of network packets as they move through various layers of the OS. The Scout OS [8] introduces a path abstraction to demarcate clearly the resources consumed by an I O path. As soon as a network packet enters the OS, it is assigned to a resource principal. All resources accessed by the packet be it system calls, interrupt handlers, or user space processing are charged to ....

O. Spatscheck and L. Petersen, \Defending Against Denial of Service Attacks in Scout," in Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI'99), Feb. 1999.

....that attackers have developed tools to coordinate distributed attacks from many separate sites [14] Unfortunately, mechanisms for dealing with denial of service have not advanced at the same pace. Most work in this area has focused on tolerating attacks by mitigating their effects on the victim [38, 2, 26, 29, 9]. This approach can provide an effective stop gap measure, but does not eliminate the problem nor does it discourage attackers. The other option, and the focus of this paper, is to trace Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted ....

O. Spatscheck and L. Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the

....solutions, and middleware solutions. Our solution roughly falls in the network centric solution category although it is fully transparent to the end server. Operating System based solutions are usually invasive and require a lot of support from the operating system. The SCOUT operating system [1, 2, 3] is an example. Such OS level support includes, but is not limited to, keeping an account of network packets as they move through various layers of the OS. This is similar to the support an OS lends to do user space process accounting. There is no proper support to do accounting for OS time spent ....

.... Then there is a generalized area of research that deals with resource containers [4] and load balancing issues[10, 11, 12, 13] Schemes have been proposed that do exhaustive resource accounting along a process s entire path through the system, an example of which is the SCOUT operating system [1, 2, 3]. A network is much more susceptible to misuse of its resources by malicious users because of the inherent distributed nature of a network. An analogy can be drawn to processor scheduling in operating systems. In a processor, the scheduler maintains multilevel hierarchical priority queues with ....

Oliver Spatscheck and Larry L. Petersen, \Defending Against Denial of Service Attacks in Scout," in Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI'99), New Orleans, Louisiana, Feb. 1999, Available online at http://www.cs.arizona.edu/scout/Papers/osdi99.ps.

....used to queue messages on a domain s channels are allocated from (and charged to) the domain s memory pool. In other words, one can think of a domain as encapsulating resources used across both the NodeOS and an EE on behalf of a packet flow, similar to resource containers [2] and Scout paths [14]. A domain is not strictly a user level entity like a Unix process. A given domain is created in the context of an existing domain, making it natural to organize domains in a hierarchy, with the root domain corresponding to the NodeOS itself. Figure 2 shows a representative domain hierarchy, ....

Oliver Spatscheck and Larry Peterson. Defending against denial of service attacks in Scout. In Proceedings of the 3rd Symp. on Operating System Design and Impl., pages 59--72, February 1999.

....ready for transmission and has put it into the I O channel to the device driver, the device driver domain has to be scheduled before the packet can be put onto the wire. In Scout, the path also comprises the driver module and thus the domain context switch can be avoided. Spatscheck and Peterson [47] have extended Scout against denial of service attacks. The system, called Escort, provides end to end resource accounting and supports multi30 ple protection domains. Resource accounting is used to protect against resource based denial of service attacks such as TCP SYN attacks, since it allows ....

O. Spatscheck and L. Peterson. Defending against denial of service attacks in Scout. In Proceedings of the 3rd USENIX Symposium on Operating Systems Design and Implementation (OSDI), New Orleans, USA, February 1999.

....typically implement a BSD style stack. There have been prior research e orts that modify the architecture of the networking stack to enable stable overload behavior [3] Other researchers have developed new operating system architectures to protect against overload and denial of service attacks [4]. Some virtual server implementations try to sandbox all resources (CPU, memory, network bandwidth) according to administrative policies and enable complete performance isolation [5] Our aim in this design, however, was not to build a new networking architecture but to introduce simple controls ....

O. Spatscheck and L. Peterson, \Defending against denial of service attacks in scout," in Proc. of OSDI, Feb. 1999.

....18] there has been limited research on the topic. Most of the existing work can be roughly categorized as being focused on tolerance, diagnosis and localization. The first category is composed of both approaches for mitigating the impact of specific attacks [4, 16] and general system mechanisms [25, 1] for controlling resource usage on the victim machine. Usually such solutions involve a quick triage on data packets so minimal work is spent on the attacker s requests and the victim can tolerate more potent attacks before failing. These solutions, as embodied in operating systems, firewalls, ....

Oliver Spatscheck and Larry Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 1999 USENIX/ACM Symposium on Operating System Design and Implementation, pages 59--72, February 1999.

....is unable to inspect the internal request stream to implement such a policy; all it knows is that the thread pool is saturated, and must arbitrarily reject work without knowledge of the source of the bottleneck. Resource containers [7] and the concept of paths from the Scout operating system [41, 49] are two techniques that can be used to bound the resource usage of tasks in a server. These mechanisms apply vertical resource management to a set of software modules, allowing the resources for an entire data flow through the system to be managed as a unit. In the case of the bottleneck ....

O. Spatscheck and L. Petersen. Defending against denial of service attacks in Scout. In Proc. 3rd Symposium on Operating Systems Design and Implementation, February 1999.

....thereby hide the identity of the physical source [4] Previous works 2 We use Internet AS topology to refer to NLANR measurement data [16] which represent only a part of the actual Internet AS graph. have focused on detecting DoS attacks and mitigating their detrimental impact upon the victim [1, 13, 24, 26]. This approach does not eliminate the problem, nor does it necessarily deter potential attackers. A number of recent works have studied source identification (also called IP traceback [23] which span a range of techniques with their individual pros and cons. In link testing, the physical source ....

O. Spatscheck and L. Peterson. Defending against denial of service attacks in Scout. In Proc. of the third USENIX/ACM Symp. on Operating Systems Design and Implementation (OSDI'99), pages 59--72, Feb. 1999.

....A. Resource control in multimedia systems Resource control has been central question in multimedia systems research for at least the past 10 years or so. Control of resources within a machine is now relatively well understood: it has been addressed in completely new operating systems (e.g. 1] [2]) modifications to existing operating systems (e.g. 3] schedulers ( 4] and abstractions ( 5] Many of these advances were motivated by the desire to handle multimedia and other time sensitive applications. Such mechanisms clearly have a place in a public computing platform designed to ....

O. Spatscheck and L. L. Peterson, "Defending Against Denial of Service Attacks in Scout," in Proceedings of the Third USENIX Symposium on Operating Systems Design and Implementation, February 1999.

....used to queue messages on a domain s channels are allocated from (and charged to) the domain s memory pool. In other words, one can think of a domain as encapsulating resources used across both the NodeOS and an EE on behalf of a packet flow, similar to resource containers [4] and Scout paths [25]. EE Fig. 2. A domain consists of channels, memory, and threads needed for EE specific processing. A given domain is created in the context of an existing domain, making it natural to organize domains in a hierarchy, with the root domain corresponding to the NodeOS itself. Figure 3 shows a ....

Oliver Spatscheck and Larry Peterson. Defending against denial of service attacks in Scout. In Proceedings of the $rd Syrup. on Operating System Design and Impl., pages 59-72, February 1999.

....flow s behalf are charged to the path. Previous research has demonstrated the usefulness of Scout paths for distributing multimedia processing across configurable network nodes [20] scheduling packet processing in a software router [23] and for protecting against denial of service (DoS) attacks [25]. Figure 1 shows a picture of a Scout TCP path. The path corresponds to a single TCP connection. It consists of a chain of protocol modules that process packets belonging to the connection, with input and output queues at each end. When a packet arrives on the network device VNET, it is ....

O. Spatscheck and L. Peterson. Defending against denial of service attacks in scout. In Proc. of OSDI, February 1999.

No context found.

Oliver Spatscheck and Larry L. Peterson. Defending against denial of service attacks in Scout. In Proc. 3rd OSDI, pages 59--72, Feb 1999.

No context found.

Oliver Spatscheck and Larry L. Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the Third Symposium on Operatin Systems Design and Implementation, February 1999.

No context found.

O. Spatscheck and L. Peterson, "Defending against denial of service attacks in Scout," in Proceedings of USENIX OSDI'99, New Orleans, LA, February 1999.

No context found.

O. Spatscheck and L. L. Peterson, "Defending Against Denial of Service Attacks in Scout," in Third Symposium on Operating Systems Design and Implementation, February 1999, pp. 59--72.

No context found.

O. Spatscheck and L. Peterson. Defending against denial of service attacks in Scout. In Proceedings of USENIX OSDI'99, New Orleans, LA, February 1999.

No context found.

O. Spatscheck and L. Peterson, "Defending against denial of service attacks in Scout," in Proceedings of USENIX OSDI'99, New Orleans, LA, February 1999.

No context found.

O. Spatscheck and L. L. Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 3rd USENIX Symposium on Operating Systems Design and Implementation, Feb. 1999.

No context found.

O. Spatscheck and L. L. Peterson. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 3rd USENIX Symposium on Operating Systems Design and Implementation, Feb. 1999.

No context found.

Oliver Spatscheck and Larry L. Peterson, "Defending Against Denial of Service Attacks in Scout," in Third Symposium on Operating Systems Design and Implemenation, February 1999, pp. 59--72.

No context found.

O. Spatscheck and L. L. Petersen. Defending against denial of service attacks in Scout. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation, February 1999.

No context found.

SPATSCHECK, O., AND PETERSON, L. L. Defending Against Denial of Service Attacks in Scout. In Third Symposium on Operating Systems Design and Implementation (February 1999), pp. 59--72.

No context found.

O. Spatscheck and L. L. Peterson, "Defending Against Denial of Service Attacks in Scout," in Third Symposium on Operating Systems Design and Implementation, February 1999, pp. 59--72.

No context found.

O. Spatscheck and L. L. Petersen. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation, February 1999.

No context found.

O. Spatscheck and L. L. Peterson. Defending against denial of service attacks in Scout. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, LA, Feb. 1999. USENIX Association.

No context found.

O. Spatscheck and L. L. Petersen. "Defending Against Denial of Service Attacks in Scout." In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation, February 1999.

No context found.

O. Spatscheck and L. Peterson. Defending against denial of service attacks in scout. In Proceedings 3rd USENIX Symposium on Operating Systems Design and Implementation, pages 45--48, New Orleans, Louisiana, February 1999.

No context found.

O. Spatscheck and L. Peterson. Defending against denial of service attacks in scout. In Proceedings of the 1999.

No context found.

Oliver Spatscheck and Larry L. Peterson. Defending against denial of service attacks in Scout. In Proc. 3rd OSDI, pages 59-72, Feb 1999.

No context found.

O. Spatscheck and L. Peterson. Defending against denial of service attacks in Scout. In 3rd USENIX Symposium on Operating Systems Design and Implementation, pages 45--58, New Orleans, Louisiana, February 1999. USENIX.

No context found.

O. Spatscheck and L. L. Petersen. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation, February 1999.

No context found.

O. Spatscheck and L. L. Petersen. Defending Against Denial of Service Attacks in Scout. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation, February 1999.

No context found.

O. Spatscheck and L. L. Peterson. Defending against denial of service attacks in scout. In Operating Systems Design and Implementation, pages 59--72, 1999.

No context found.

Oliver Spatscheck and Larry L. Peterson. Defending against denial of service attacks in Scout. In Proc. 3rd OSDI, pages 59--72, Feb 1999.

No context found.

O. Spatscheck and L. Petersen, "Defending Against Denial of Service Attacks in Scout," in Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI'99), Feb. 1999.

No context found.

O. Spatscheck and L. Peterson. Defending against denial of service attacks in scout. In Proc. of OSDI, February 1999. 13

No context found.

Oliver Spatscheck and Larry Peterson. Defending against denial of service attacks in Scout. In Proceedings of the 3rd Usenix Symposium on Operating Systems Design and Implementation (OSDI), pages 59--72, New Orleans, LA, February 1999.

No context found.

Oliver Spatscheck and Larry Peterson, "Defending against denial of service attacks in scout," in Proceedings of the 1999 USENIX/ACM Symposium on Operating System Design and Implementation, February 1999.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC