This paper describes a technique for tracing anonymous packet flooding attacks in the Internet back towards their source. This work is motivated by the increased frequency and sophistication of denial-of-service attacks and by the difficulty in tracing packets with incorrect, or “spoofed”, source addresses. In this paper we describe a general purpose traceback mechanism based on probabilistic packet marking in the network. Our approach allows a victim to identify the network path(s) traversed by attack traffic without requiring interactive operational support from Internet Service Providers (ISPs). Moreover, this traceback can be performed “post-mortem ” – after an attack has completed. We present an implementation of this technology that is incrementally deployable, (mostly) backwards compatible and can be efficiently implemented using conventional technology. 1.

Attackers can render distributed denial-ofservice attacks more difficult to defend against by bouncing their flooding traffic off of reflectors; that is, by spoofing requests from the victim to a large set of Internet servers that will in turn send their combined replies to the victim. The resulting dilution of locality in the flooding stream complicates the victim's abilities both to isolate the attack traffic in order to block it, and to use traceback techniques for locating the source of streams of packets with spoofed source addresses, such as ITRACE [Be00a], probabilistic packet marking [SWKA00], [SP01], and SPIE [S+01]. We discuss a number of possible defenses against reflector attacks, finding that most prove impractical, and then assess the degree to which different forms of reflector traffic will have characteristic signatures that the victim can use to identify and filter out the attack traffic. Our analysis indicates that three types of reflectors pose particularly significant threats: DNS and Gnutella servers, and TCP-based servers (particularly Web servers) running on TCP implementations that suffer from predictable initial sequence numbers. We argue in conclusion in support of "reverse ITRACE" [Ba00] and for the utility of packet traceback techniques that work even for low volume flows, such as SPIE.

Transmission Control Protocol (TCP) assumes a relatively reliable underlying network where most packet losses are due to congestion. In a wireless network, however, packet losses will occur more often due to unreliable wireless links than due to congestion. When using TCP over wireless links, each packet loss on the wireless link results in congestion control measures being invoked at the source. This causes severe performance degradation. In this paper, we study the effect of (a) burst errors on wireless links, (b) packet size variation on the wired network, (c) local error recovery by the base station, and (d) explicit feedback by the base station, on the performance of TCP over wireless networks. It is shown that the performance of TCP is sensitive to the packet size, and that significant performance improvements are obtained if a `good' packet size is used. While local recovery by the base station using link-level retransmissions is found to improve performance, timeouts can still ...

This paper is a draft that will appear in IEEE/ACM Transactions on Networking. Final editing is still expected. Please replace it with the final version when published.

There are considerable efforts within the Grid and high performance computing communities to improve end-to-end network performance for applications that require substantial amounts of network bandwidth. The Atlas project [19] for example, must be able to reliably transfer over 2 Petabytes of data per year over transatlantic networks from Europe to the United States. Recent experience [1, 2] has demonstrated that actual aggregate TCP throughput realized by high performance applications is persistently much less than the end-to-end structural and load characteristics of the network would indicate is available. One source of poor TCP throughput that has been identified is a packet loss rate that is much greater than what would be reasonably expected [20]. Packet loss is interpreted by TCP as an indication of network congestion between a sender and receiver. Packet loss, however, may be due to random factors other than network congestion, such a

Active Networks promise greater #exibility than current networks, but threaten safety and securityby virtue of their programmability.

Application layer proxies already play an important role in today's networks, serving as firewalls and HTTP caches --- and their role is being expanded to include encryption, compression, and mobility support services. Current application layer proxies suffer major performance penalties as they spend most of their time moving data back and forth between connections; context switching and crossing protection boundaries for each chunk of data they handle. We present a technique called TCP Splice that provides kernel support for data relaying operations which runs at near router speeds. In our lab testing, we find SOCKS firewalls using TCP Splice can sustain a data throughput twice that of normal firewalls, with an average packet forwarding latency 30 times less. KEYWORDS: TCP, Firewalls, SOCKS, Application Layer Proxies, Performance 1. INTRODUCTION Many designs for Internet services use split-connection proxies, in which proxy machine is interposed between the server and the client ma...

With the success of the Internet and flexibility of MPEG-4, transporting MPEG-4 video over the Internet is expected to be an important component of many multimedia applications in the near future. Video applications typically have delay and loss requirements, which cannot be adequately supported by the current Internet. Thus, it is a challenging problem to design an efficient MPEG-4 video delivery system that can maximize the perceptual quality while achieving high resource utilization. This paper addresses this problem by presenting an end-to-end architecture for transporting MPEG-4 video over the Internet. We present a framework for transporting MPEG-4 video, which includes source rate adaptation, packetization, feedback control, and error control. The main contributions of this paper are: 1) a feedback control algorithm based on Real Time Protocol (RTP) and Real Time Control Protocol (RTCP); 2) an adaptive source-encoding algorithm for MPEG-4 video which is able to adjust the output rate of MPEG-4 video to the desired rate; and 3) an efficient and robust packetization algorithm for MPEG video bit-streams at the sync layer for Internet transport. Simulation results show that our end-to-end transport architecture achieves good perceptual picture quality for MPEG-4 video under low bit-rate and varying network conditions and efficiently utilizes network resources.

This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ‘‘work in progress.’’ To learn the current status of any Internet-Draft, please check the ‘‘1id-abstracts.txt’ ’ listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the ’options ’ field of the DHCP message. The data items themselves are also called "options." This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in

Many companies, organizations and communities are providing wireless hotspots that provide networking access using 802.11b wireless networks. Since wireless networks are more sensitive to variations in bandwidth and environmental interference than wired networks, most networks support a number of transmission rates that have different error and bandwidth properties. Access points can communicate with multiple clients running at different rates, but this leads to unfair bandwidth allocation. If an access point communicates with a mix of clients using both 1mb/s and 11mb/s transmission rates, the faster clients are effectively throttled to 1mb/s as well. This happens because the 802.11 MAC protocol approximate "station fairness", with each station given an equal chance to access the media. We provide a solution to provide "rate proportional fairness", where the 11mb/s stations receive more bandwidth than the 1mb/s stations. Unlike previous solutions to this problem, our mechanism is easy to implement, works with common operating systems and requires no change to the MAC protocol or the stations.