From chk at pobox.com Wed Jan 4 07:23:34 2006 From: chk at pobox.com (Harald Koch) Date: Wed, 4 Jan 2006 10:23:34 -0500 Subject: [e2e] Can we revive T/TCP ? => persistent connections References: <001301c60a4a$9831dc60$0200a8c0@fun> <000901c60a57$0ccaaf00$0200a8c0@fun> Message-ID: <02ec01c61144$32716b60$096355c7@americas.hpqcorp.net> > In practice, this doesn't seem to be the case. In all the tests my > students did (not a thorough measurement study, just some > experiments), the server closed the connection after sending a page. IME, this is most commonly caused by the webserver not knowing the size of a dynamically generated page in advance. When the webserver cannot send a Content-Length: header, it must close the connection to signal "end of page" instead. -- Harald Koch chk at pobox.com From zhani_med_faten at yahoo.fr Fri Jan 6 12:02:47 2006 From: zhani_med_faten at yahoo.fr (Zhani Mohamed Faten) Date: Fri, 6 Jan 2006 21:02:47 +0100 (CET) Subject: [e2e] Analysis of RTT Message-ID: <20060106200247.90090.qmail@web25710.mail.ukl.yahoo.com> Hi - I have a capture of traffic (30 mn - erf format) from one link. I would like to have some information about how to calculate the RTT analyticallay and from the trace (if there is a particular tool). I found this page which discuss this problem but I would like to discuss the problem especially if my aim is to find relation between the RTT and the granularity used to analyse the traffic. http://swig.stanford.edu/pub/summaries/networks/rtt.html - I would like to know if there is a way to distinguish connection that are congestioned from that they aren't and then calculate RTT thank you --------------------------------- Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.T?l?chargez la version beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060106/7be587fb/attachment.html From falk at ISI.EDU Fri Jan 6 09:45:51 2006 From: falk at ISI.EDU (Aaron Falk) Date: Fri, 6 Jan 2006 09:45:51 -0800 Subject: [e2e] CFP: Workshop on Protocols for Fast Long-Distance Networks (PFLDnet2006) References: Message-ID: <152579C5-0FEC-4307-B34E-727376CB116C@isi.edu> Call For Participant =============== Fourth International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet2006) February 2-3, 2006 Nara, Japan - An ancient capital city older than Kyoto ------------------------------------------------------------------------ http://www.hpcc.jp/pfldnet2006/ ------------------------------------------------------------------------ Fast long-distance networks (i.e., networks operating at 622 Mbit/s, 2.5 Gbit/s, or 10 Gbit/s, soon will be 40 Gbit/s, and spanning several countries or states) are now becoming commonplace. Increasing numbers of researchers now routinely transfer between 10 GB and multi-TB datasets over gigabit networks. Application domains for such massive transfers include data-intensive Grids (e.g., in Particle Physics, Earth Observation, Bio Informatics, and Radio Astronomy), database mirroring for Web sites (e.g., in e-commerce), and push-based Web cache updates. Although the connectivity infrastructure is now in place, or will soon be, the transport and application protocols available to date are proving inadequate for fast transfer of large volumes of data over such networks. Current versions of TCP cannot fully exploit the network capacity. For instance, recovery time from a congestion event grows at a super-linear rate, and can easily exceed 10 minutes in very high bandwidth-delay product networks. It also requires a large congestion window for high throughput, consuming valuable system resources. A number of research teams have begun investigating advanced protocols for domain-specific and general applications. The International Workshop on Protocols for Fast Long-Distance Networks in CERN (http://datatag.web.cern.ch/datatag/pfldnet2003/), in Argonne (http://www-didc.lbl.gov/PFLDnet2004/), and in Lyon (http://www.ens-lyon.fr/LIP/RESO/pfldnet2005/) were very successful in bringing together many researchers from all over the world including North America, Europe and Asia who are working on these problems. This workshop will continue this tradition, and provide a perfect setting for researchers in this area to exchange ideas and experience. This single-track workshop will provide researchers and technologists with a focused, highly interactive opportunity to present, discuss and exchange experience on leading research, development and future directions in high performance transport and application protocols (TCP, UDP, HTTP, FTP, etc.) over fast long-distance networks. In order to facilitate discussions, attendance will be limited to 60 participants. Please register early to ensure your participation. Depending on the number of people who register, we may need to restrict the number of people from a given organization to allow for a broader representation of the research community. Registration ------------ The registration information is shown in: http://www.hpcc.jp/pfldnet2006/regist.html ADVANCE REGISTRATION On or Before 17:00 January 13, 2006 / Japan Standard Time (GMT+9) General JPY 30,000 Student JPY 15,000 STANDARD/ON-SITE REGISTRATION After 17:00 January 13, 2006 / Japan Standard Time (GMT+9) General JPY 40,000 Student JPY 20,000 Scope ----- The PFLDnet2006 workshop will focus on research issues and challenges as well as lessons learned from experience. Topics of interest include and are not limited to: - Protocol issues in fast long-distance networks - Enhancements of TCP and its variants - Novel data transport protocols designed for new application services - Transport over optical networks - RDMA over WANs - Shaping on TCP and UDP traffic - QoS and scalability issues - Parallel transfers and multistreaming - Multicast over fast long-distance networks - Modeling and simulation-based results - Experiments on real networks and actual measurements - Protocol benchmarking - Protocol implementation and hardware issues (PCs, NICs, TOEs, routers, switches, etc.) - Data replications and striping - Requirements and experience from bandwidth demanding applications - Bulk-data transfer applications both TCP and non-TCP based - Transport service for Grids Important Dates --------------- Advance Registration Deadline: January 13 Final Paper Submission: January 20 Workshop: February 2-3 Committees ---------- Co-Chairs: Richard Hughes-Jones (Univ. Manchester - UK) Kei Hiraki (Univ. of Tokyo - JP) Jason Leigh (UIC - USA) Steering Committee: Pascale Vicat-Blanc Primet (INRIA - FR) Tomohiro Kudoh (AIST - JP) Katsushi Kobayashi (NICT - JP) Technical Program Committee : Brian L Tierney (LBL - USA) R. Les Cottrell (SLAC - USA) Bill Allcock (ANL - USA) Eitan Altman (INRIA - FR) Richard Carlson (Internet2 - USA) Sally Floyd (ICIR - USA) Pascale Vicat-Blanc Primet (INRIA - FR) Tomohiro Kudoh (AIST - JP) Douglas Leith (Hamilton Institute - IR) Steven Low (CALTECH - USA) Medy Sanadidi (UCLA - USA) Robin Tasker (CCLRC - UK) Hideyuki Shimonishi (NEC - JP) Kenjiro Cho (IIJ - JP) Injong Rhee (NCSU - USA) Andrew Chien (UCSD - USA) Aaron Falk (ISI - USA) Saverio Mascolo (Politecnico di Bari - IT) Katsushi Kobayashi (NICT - JP) Local Organization Committee: Noritoshi Demizu (NICT - JP) Sponsors -------- NICT, JAPAN Juniper Networks Contact ------- pfldnet2006-la at hpcc.jp Program (draft) --------------- February 2nd: 08:30-09:00 Registration and Breakfast 09:00-10:20 Opening and Keynote 1 Kei Hiraki (University of Tokyo) 10:20-10:40 Break 10:40-12:00 Session 1: New ideas "Evaluating the Performance of TCP Stacks for High-Speed Networks" B. Even, Y. Li, and D.J. Leith (Hamilton Institute) (30 min.) "Large Scale Gigabit Emulated Testbed for Grid Transport Evaluation" P. Vicat-Blanc Primet*, R. Takano***, Y. Kodama**, T. Kudoh**, O. Gluck*, and C. Otal* (ENS Lyon*, AIST**, AXE Inc.***) (20 min.) "Studying Multi-rate Multicast Congestion Control with Explicit Router Feedback" K. Nakauchi and K. Kobayashi (NICT) (30 min.) 12:00-13:00 Lunch 13:00-14:20 Session 2: TCP issues "Impact of Drop Synchronisation on TCP Fairness in High Bandwidth-Delay Product Networks" D.J. Leith and R. Shorten (Hamilton Institute) (30 min.) "The effect of reverse traffic on the performance of new TCP congestion control algorithms for gigabit networks" S. Mascolo and F. Vacirca (Politecnico di bari) (20 min.) "A Step toward Realistic Performance Evaluation of High-Speed TCP Variants" Sangtae Ha, Yusung Kim, Long Le, Injong Rhee, and Lisong Xu* (NCSU, UNL*) (30 min.) 14:20-14:50 Break 14:50-15:50 Session 3: Implementation issues "Transmission Timer Approach for Rate Based Pacing TCP with Hardware Support" K. Kobayashi (NICT) (20 min.) "Inline Path Characteristic Estimation to Improve TCP Performance in High Bandwidth-Delay Networks" C. Marcondes, A. Persson, M.Y. Sanadidi and M. Gerla (UCLA) (20 min.) "A Case for UDP offload Engines in LambdaGrids" V. Vishwanathz, P. Balaji*, W. Feng**, J. Leigh, and D. K. Panda* (UIC, OSU*, LANL**) (20 min.) 15:40-16:10 Break 16:10-17:40 Panel TBD February 3rd: 08:30-09:00 Breakfast 09:00-10:00 Keynote 2 Michael Chen (Chelsio Communications) 10:00-10:30 Break 10:30-11:50 Session 4: TCP variant "Compound TCP: A Scalable and TCP-Friendly Congestion Control for High-speed Networks" Kun Tan Jingmin Song, Qian Zhang*, and Murari Sridharan** (Microsoft Research Asia, HK Univ of Science & Technology*, Microsoft Corp.**) (30 min.) "Analysis of TCP Westwood+ in high speed networks" E. Altman, C. Barakat, S. Mascolo, N. Moller, and J. Sun (INRIA) (30 min.) "TCP-Adaptive Reno: Improving Efficiency-Friendliness Tradeoffs of TCP Congestion Control Algorithm" H. Shimonishi, T. Hama, and T. Murase (NEC Corp.) (20 min.) 11:50-12:50 Lunch 12:50-14:00 Session 5: Performance evaluations on production networks "Experimental Results of TCP/IP data transfer On 10Gbps IPv6 Network" J. Tamatsukuri, K. Inagami, M. Inaba, and K. Hiraki (Univ. Tokyo)(20 min.) "Can high-speed transport protocols be deployed on the Internet? : Evaluation through experiments on JGNII" K. Kumazoe, K. Kouyama*, Y. Hori**, M. Tsuru***, and Yuji Oie*** (NICT, KEPCO*, Kyushu Univ.**, Kyushu Institute of Technology***) (30 min.) "Realtime Burstiness Measurement" R. Takano *&**, Y. Kodama*, T. Kudoh*, M. Matsuda*, F. Okazaki*, and Y. Ishikawa*** (AIST*, AXE Inc.**, Univ. of Tokyo***) (20 min.) 14:00:14:30 Break 14:30-15:30 Session 6: Light path issues "Paced XCP for Small Buffered Optical Packet Switching Networks" O. Alparslan, S. Arakawa, and M. Murata (Osaka Univ.) (20 min.) "Evaluation of End-node Based Rate Allocation Schemes for Lambda-Networks" Xinran (Ryan) Wu and Andrew A. Chien (UCSD) (20 min.) "Lightpaths for Protocol Performance" K. Roberts (Nortel) (20 min.) 15:30-15:50 Break 15:50-17:20 Panel TBD 17:20-17:50 Closing -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060106/05b752aa/PGP.bin From dina at csail.mit.edu Mon Jan 9 08:28:37 2006 From: dina at csail.mit.edu (Dina Katabi) Date: Mon, 09 Jan 2006 11:28:37 -0500 Subject: [e2e] CFP for Usenix SRUTI' 06 Message-ID: <43C28F35.4030505@csail.mit.edu> ------------------------------------------------------------------ SRUTI' 06: Steps to Reducing Unwanted Traffic on the Internet USENIX Workshop (July 6-7, 2006 in San Jose, CA) URL: http://www.usenix.org/events/sruti06/ -------------------------------------------------------------------- The Internet is under increasing attack with unwanted traffic in the form of spam, distributed denial of service, virus, worms, etc. Unwanted traffic on the Internet has manifested itself as attacks via many protocols (IP, TCP, DNS, BGP, and HTTP) and popular applications (e.g., email, Web). Often, these attacks have a direct economic motivation. SRUTI seeks research on the unwanted traffic problem that looks across the protocol stack, examines attack commonalities, and investigates how various solutions interact and whether they can be combined to increase security. Original research, promising ideas, and steps toward practical solutions at all levels are sought. We look for ideas in networking and systems, and insights from other areas such as databases, data mining, and economics. SRUTI aims to bring academic and industrial research communities together with those who face the problems at the operational level. SRUTI is a one-and-a-half-day event. Each session chair will play the role of a discussant and present a summary of the papers in the session and a state-of-the-art synopsis of the topic. The workshop will be highly interactive, with substantial time devoted to questions and answers. Submissions must contribute to improving the current understanding of unwanted traffic and/or suggestions for reducing it. The Proceedings of the workshop will be published. To ensure a productive workshop environment, attendance will be by invitation and/or acceptance of paper submission. IMPORTANT DATES Submissions due: Thursday, April 20, 2006, 0400 UTC Notification of acceptance: Thursday, May 18, 2006 Final papers due: Tuesday, June 6, 2006 PROGRAM CHAIR Steven M. Bellovin, Columbia University PROGRAM COMMITTEE Harald Alvestrand, Cisco Dan Boneh, Stanford University Jon Crowcroft, Cambridge University Anja Feldmann, Technische Universit?t M?nchen John Ioannidis, Columbia University Balachander Krishnamurthy, AT&T Labs?Research Chris Morrow, UUnet Vern Paxson, ICIR/ICSI Niels Provos, Google Eric Rescorla, Network Resonance Tara Whalen, Dalhousie University PUBLICITY CHAIR Lakshminarayanan Subramanian STEERING COMMITTEE Dina Katabi, MIT Balachander Krishnamurthy, AT&T Labs?Research Ellie Young, USENIX Clem Cole, Ammasso, USENIX Liaison From bkarp at cs.ucl.ac.uk Tue Jan 10 13:55:56 2006 From: bkarp at cs.ucl.ac.uk (SIGCOMM 2006) Date: Tue, 10 Jan 2006 21:55:56 +0000 Subject: [e2e] ACM SIGCOMM 2006 Call for Papers Message-ID: <20060110215556.GB31021@smelt.bkarp.co.uk> Dear Colleague, We would like to encourage you to submit research papers to SIGCOMM 2006--the premier conference on networking and computer communications--which will be held in Pisa, Italy on September 11th-15th. The CFP is attached below. Our intent is for SIGCOMM 2006 to be very broad, inclusive of work across the entire spectrum of networking research, including wireless, network security, sensor networks, overlay, and peer-to-peer systems, in addition to more traditional SIGCOMM topics. To help encourage that breadth, we intend to accept approximately 50% more papers than in previous years. With your help, we believe this will lead to three very full, but also very interesting, days at the conference. Further, we note that throughout the network research community, there is renewed interest in network architecture, and what the future Internet might be in 15-20 years. Fundamental "clean slate" approaches and radical new ideas are definitely encouraged. We look forward to reading your submissions and to seeing you in Pisa in September. Regards, Tom Anderson & Nick McKeown PC Chairs, SIGCOMM 2006 --- CALL FOR PAPERS ACM SIGCOMM 2006 Conference Pisa, Italy September 11th-15th, 2006 IMPORTANT DATES Workshop/Tutorial Proposals: November 15th, 2005 Paper registration/abstract: February 3rd, 2006 (required, hard deadline) Paper submission: February 10th, 2006 (hard deadline) Paper notification: May 1st, 2006 Camera-ready papers: June 21st, 2006 Please note that notifications to authors will occur in "rolling" fashion; that is, authors may receive decisions anytime between the submission deadline and notification date. The SIGCOMM 2006 conference seeks papers describing significant research contributions to the field of computer and data communication networks. We invite submissions on network architecture, design, implementation, operations, analysis, measurement, and simulation. Areas of interest include, but are not limited to: * Analysis and design of network architectures and algorithms * Experimental and measurement results from operational networks * Fundamental insights into network and traffic characteristics * Network fault-tolerance and reliability, debugging, and troubleshooting * Network management and traffic engineering * Network security, vulnerability, and defenses * Network, transport, and application-layer protocols * Networking issues for Web, multimedia, and gaming applications * Operating system and other host support for networking * Peer-to-peer, overlay, and content distribution networks * Resource management, quality of service, and signaling * Routing, switching, and addressing * Tools and techniques for network measurement and simulation * Wireless, mobile, ad-hoc, and sensor networks SIGCOMM 2006 solicits full papers up to 12 pages in length, in two-column ACM conference format. SIGCOMM is a selective conference where full papers typically report novel results firmly substantiated by experimentation, simulation, or analysis. We intend to publish public reviews of each accepted paper, to be written by the program committee. We also plan to host an open web discussion board for accepted papers prior to the conference. As in previous years, SIGCOMM 2006 will have tutorials, workshops, a poster session, a student travel grant program, and a Student Paper Award. Details will be posted as they become available on the conference web site: http://www.acm.org/sigcomm/sigcomm2006/ The conference will begin with a keynote by the 2006 winner of the ACM SIGCOMM Award for lifetime contributions to the field of computer communication. Procedures for nominating candidates for the SIGCOMM Award can be obtained from Jennifer Rexford, jrex at cs.princeton.edu. ORGANIZATION General Chair: Luigi Rizzo, Universita di Pisa Program Chairs: Tom Anderson, University of Washington Nick McKeown, Stanford University Conference Coordinator: Joe Touch, USC/Information Sciences Institute Local Organization Chair: Giovanni Stea, Universita di Pisa Treasurer: Gianluca Iannaccone, Intel Research Cambridge Publicity Chair: Brad Karp, University College London Workshop Chairs: Christophe Diot, Thomson, Paris Serge Fdida, University Paris 6, France Tutorial Chair: Marco Conti, IIT-CNR, Pisa From balabanga at yahoo.com Fri Jan 13 11:34:15 2006 From: balabanga at yahoo.com (Balaji Ramachandran) Date: Fri, 13 Jan 2006 11:34:15 -0800 (PST) Subject: [e2e] Network protocol distribution Message-ID: <20060113193415.13396.qmail@web51112.mail.yahoo.com> Hi all , I was in the process of designing a statistics module for a network device. In order to save on memory and computation, the design was going to assume that a small number of protocols is going to generate a large amount of traffic (something like a 80 - 20 rule). This was just an intuition, so it to have some proven basis, in the context of public and private networks. I tried to search for relevant literature, but found nothing (I used the wrong keywords may be). It would be most useful if I could be poitned to some relevant literature in this area. thanks Balaji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From volkerh at bell-labs.com Sat Jan 14 04:08:32 2006 From: volkerh at bell-labs.com (Volker Hilt) Date: Sat, 14 Jan 2006 07:08:32 -0500 Subject: [e2e] CfP: ISET 2006 Message-ID: <43C8E9C0.6030704@bell-labs.com> (Our apologies if you receive multiple copies of this CFP) ---------------------------------------------------------------------- Call for Papers Symposium on Internet Services and Enabling Technologies (ISET) http://iset.internettc.org/ http://www.ieee-globecom.org/2006/internet.html in conjunction with IEEE Globecom 2006, San Francisco, California, USA Nov 27 - Dec 1, 2006 Scope ----- Over the past decade, the Internet has revolutionized the way people communicate and do business, driving the emergence of new and exciting applications. As the Internet has matured, the focus of innovation is shifting to the development of new applications and services, and their enabling technologies. This symposium is intended to bring together the academics and industrialists engaged in this field, and exchange information about advances in the field and speculate about the future (r)evolution. The Symposium on Internet Services and Enabling Technologies targets academic and industrial research activities that are focused on techniques to improve the delivery of services over the Internet, both wireline and wireless. It encompasses the design, implementation, and management of networked services and applications, as well as underlying protocols and technologies that enable them, including, for example, SIP, P2P technologies, network virtualization, and presence information. Related areas include the high-level architectures and design frameworks that are used by networking consultants and designers to develop new Internet services, or manage their operations. Of particular interest are original speculations about the future of Internet services and their enabling technologies, compelling position papers, and submissions describing promising work in progress. Topics of Interest ------------------ Topics of particular interest include, but are not limited to the following: * Services enabling protocols and protocol extensions (including SIP, HTTP, RTSP, RTP, etc.) * Peer-to-Peer applications and technologies that leverage/support peer-to-peer applications * Middleware for new Internet based applications * Converged networks and applications (including VoIP and 3G/NGN telecom networks) * Applications leveraging content networking technologies * Application paradigms (e.g. endpoint-hosted vs. network-hosted) * Software as a service model for delivering applications on the Internet * Services over the wireless Internet (including services on ad-hoc and sensor networks) * Security and privacy management in hosted Internet applications * Platforms for rapid creation and deployment of network services * Design methodologies for Internet services * Systems and architectures for hosting Internet facing services * Call center operations and global sourcing of services and applications * Emergency services * Service delivery, service assurance, and root-cause analysis of service problems * Financial and business tools needed for Internet based services Important Dates --------------- Paper Manuscripts Due: 5 March 2006, 11:59pm EST Paper Acceptance Notification: 5 July 2006 Camera-Ready Manuscripts Due: 30 August 2006 Symposium Co-Chairs ------------------- Volker Hilt, Bell Labs/Lucent Technologies, volkerh at bell-labs.com Anees Shaikh, IBM TJ Watson Research Center, aashaikh at watson.ibm.com Technical Program Committee --------------------------- Kevin Almeroth (University of California at Santa Barbara) Supratik Bhattacharyya (Sprint ATL) Torsten Braun (University of Berne) Gonzalo Camarillo (Ericsson) Christophe Diot (Thomson) Igor Faynberg (Bell Labs/Lucent Technologies) Werner Geyer (IBM T.J. Watson Research) Marco Gruteser (WINLAB / Rutgers University) Volker Hilt (Bell Labs/Lucent Technologies) Markus Hofmann (Bell Labs/Lucent Technologies) Hani Jamjoom (IBM T.J. Watson Research Center) Sneha Kasera (University of Utah) Martin Mauve (Heinrich-Heine Universit?t D?sseldorf) Srihari Nelakuditi (University of South Carolina) G?nter Sch?fer (Technische Universit?t Ilmenau) Aman Shaikh (AT&T Labs - Research) Anees Shaikh (IBM TJ Watson Research Center) Burkhard Stiller (ETHZ) Joe Touch (USC/ISI) J?rgen Vogel (European Media Laboratory) Lan Wang (University of Memphis) Lars Wolf (TU Braunschweig, IBR) From rhee at eos.ncsu.edu Mon Jan 16 14:12:46 2006 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Mon, 16 Jan 2006 17:12:46 -0500 Subject: [e2e] Performance evaluation of high speed TCPs Message-ID: <200601162212.k0GMCpv8009124@uni02mr.unity.ncsu.edu> We have just finished our first series of performance evaluation of 6 different high TCP variants that have been recently proposed. We have a report on the results below: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/asteppaper.htm This report has been long overdue and can be considered as our response to earlier test reports by other folks publicized in several mailing lists. What is unique about our report is that we emphasize on the importance of background traffic in experimental evaluation of congestion control protocols. The results we got with background traffic are quite different from what are reported in one of the earlier reports. It is not unknown that background traffic makes difference in protocol performance, but it is unknown how they make difference and what properties may change. Please view the report and follow the embedded links in the report to get more information about experiment. The performance pictures in the report are a little blurred due to resizing. But if you follow the html links associated with each picture you can get a better picture of it and more information about it. While we're preparing this report, we found that there are many testing scenarios that we need to cover, yet it is difficult to come up with a meaning scenario that could change protocol behaviors in a meaningful way. So we would like to solicit your opinion on types of testing scenarios you want to see. Also if you have other protocols that you like to see it being tested in the same environment, please let us know as well. Thanks Injong ---- Injong Rhee Associate Professor Department of Computer Science North Carolina State University http://www.csc.ncsu.edu/faculty/rhee From rhee at eos.ncsu.edu Mon Jan 16 16:41:52 2006 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Tue, 17 Jan 2006 09:41:52 +0900 Subject: [e2e] Performance evaluation of high speed TCPs In-Reply-To: <007401c61afc$5b6c68f0$23d25ba5@tamu.edu> Message-ID: <200601170042.k0H0gB4p014124@ms-smtp-02-eri0.southeast.rr.com> Reddy, Sure. This is the first set of the test. So we plan to add more TCP stacks as they become available. If you have a linux implementation of LTCP 2.6.13 or higher, we will add it in our test script. Thanks Injong Injong Rhee, Associate Professor North Carolina State University Raleigh, NC 27699 rhee at eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee > -----Original Message----- > From: Narasimha Reddy > [mailto:reddy at ece.tamu.edu] > Sent: Tuesday, January 17, 2006 9:24 AM > To: 'Injong Rhee'; end2end-interest at postel.org > Cc: 'Long Le'; rhee at ncsu.edu; 'Yusung Kim'; > 'Lisong Xu' > Subject: RE: [e2e] Performance evaluation of > high speed TCPs > > Injong, I am sure you are aware of LTCP > http://www.ece.tamu.edu/~reddy/papers/pfld05.pdf > . > I understand that it may not have been possible > to evaluate all proposed > protocols, but I hope you include it in your > future evaluations. > > Thanks > Reddy > > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On > Behalf Of Injong Rhee > Sent: Monday, January 16, 2006 4:13 PM > To: end2end-interest at postel.org > Cc: 'Long Le'; rhee at ncsu.edu; 'Yusung Kim'; > 'Lisong Xu' > Subject: [e2e] Performance evaluation of high > speed TCPs > > We have just finished our first series of > performance evaluation of 6 > different high TCP variants that have been > recently proposed. We have > a report on the results below: > > http://www.csc.ncsu.edu/faculty/rhee/export/bitc > p/asteppaper.htm > > This report has been long overdue and can be > considered as our > response to earlier test reports by other folks > publicized in several > mailing lists. What is unique about our report > is that we emphasize > on the importance of background traffic in > experimental evaluation of > congestion control protocols. The results we got > with background > traffic are quite different from what are > reported in one of the > earlier reports. It is not unknown that > background traffic makes > difference in protocol performance, but it is > unknown how they make > difference and what properties may change. > > Please view the report and follow the embedded > links in the report to > get more information about experiment. The > performance pictures in the > report are a little blurred due to resizing. But > if you follow the > html links associated with each picture you can > get a better picture > of it and more information about it. > > While we're preparing this report, we found that > there are many > testing scenarios that we need to cover, yet it > is difficult to come > up with a meaning scenario that could change > protocol behaviors in a > meaningful way. So we would like to solicit your > opinion on types of > testing scenarios you want to see. Also if you > have other protocols > that you like to see it being tested in the same > environment, please > let us know as well. > > Thanks > Injong > ---- > Injong Rhee > Associate Professor > Department of Computer Science > North Carolina State University > http://www.csc.ncsu.edu/faculty/rhee > > From mascolo at poliba.it Tue Jan 17 08:18:53 2006 From: mascolo at poliba.it (Saverio Mascolo) Date: Tue, 17 Jan 2006 17:18:53 +0100 Subject: [e2e] Performance evaluation of high speed TCPs References: <200601162212.k0GMCpv8009124@uni02mr.unity.ncsu.edu> Message-ID: <014b01c61b81$bf128170$703bccc1@yourf1911fedb6> hi, we have shown effect of reverse traffic on TCP Vegas, New Reno and Westwood+ in an ACM CCR paper (april 2004) you can find here: http://193.204.59.68/mascolo/tcp%20westwood/ccr_v31.pdf historically we were "forced" to look at reverse traffic because congestion on the ack path (and ack compression) was provoking bad behaviour of Westwood TCP, which is also shown in the paper above. the reason was bandwidth overestimate because we were computing bandwdith samples every ack and smaples were aliased (see http://193.204.59.68/mascolo/recent_papers/Grieco_Mascolo_3621_QoSIP03.pdf ) other result was that Vegas TCP is heavily affected by reverse traffic because of queuing on reverse path. similar sensitivity to reverse traffic have been found with FAST TCP in a paper appearing at pfldnet06 and also in tests done by les cottrel. best, saverio ----- Original Message ----- From: "Injong Rhee" To: Cc: "'Long Le'" ; ; "'Yusung Kim'" ; "'Lisong Xu'" Sent: Monday, January 16, 2006 11:12 PM Subject: [e2e] Performance evaluation of high speed TCPs > We have just finished our first series of performance evaluation of 6 > different high TCP variants that have been recently proposed. We have > a report on the results below: > > http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/asteppaper.htm > > This report has been long overdue and can be considered as our > response to earlier test reports by other folks publicized in several > mailing lists. What is unique about our report is that we emphasize > on the importance of background traffic in experimental evaluation of > congestion control protocols. The results we got with background > traffic are quite different from what are reported in one of the > earlier reports. It is not unknown that background traffic makes > difference in protocol performance, but it is unknown how they make > difference and what properties may change. > > Please view the report and follow the embedded links in the report to > get more information about experiment. The performance pictures in the > report are a little blurred due to resizing. But if you follow the > html links associated with each picture you can get a better picture > of it and more information about it. > > While we're preparing this report, we found that there are many > testing scenarios that we need to cover, yet it is difficult to come > up with a meaning scenario that could change protocol behaviors in a > meaningful way. So we would like to solicit your opinion on types of > testing scenarios you want to see. Also if you have other protocols > that you like to see it being tested in the same environment, please > let us know as well. > > Thanks > Injong > ---- > Injong Rhee > Associate Professor > Department of Computer Science > North Carolina State University > http://www.csc.ncsu.edu/faculty/rhee > > From zm at cernet.edu.cn Tue Jan 17 16:40:15 2006 From: zm at cernet.edu.cn (Zhang Miao) Date: Wed, 18 Jan 2006 08:40:15 +0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address Message-ID: Hi, I just have a question related to DDoS Attack and Spoofing of Source Address. It was common for the DDoS attack to utilize the spoofed source address two years ago. And many people told me, it is botnets the main way to launch DDoS attack, in which source address is not spoofed. I'm just curious on the following questions: (1) What's the situation of the DDoS attack nowadays? Is spoofing of source address still a major reason for the DDoS attack? (2) If most of DDoS attack has shift from using spoofing of source address to using botnets, why such shift happens? I suppose two reasons: 1) Ingress filter has been deployed in many ISPs, and attacker feel it's hard to launch such attack now. 2) It's easier to launch attack with botnets than with spoofed source address. But I am not sure about it. (3) Is it easier to handle DDoS attack if the source address in the packet is authentic? I'm quite grateful to your answers. Miao ***************************************************************** * Zhang Miao * * Ph.D, Assistant Professor, Network Research Center * * Tsinghua University,Beijing,China(100084) * * Tel: (8610)-62795818-6271 * * Email: zm at cernet.edu.cn * * Web: http://netarchlab.tsinghua.edu.cn/~zm * ***************************************************************** From jeroen at unfix.org Tue Jan 17 17:15:00 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 18 Jan 2006 02:15:00 +0100 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: References: Message-ID: <43CD9694.1050204@unfix.org> Zhang Miao wrote: > Hi, > > I just have a question related to DDoS Attack and Spoofing of Source Address. > > It was common for the DDoS attack to utilize the spoofed source address > two years ago. And many people told me, it is botnets the main way > to launch DDoS attack, in which source address is not spoofed. > > I'm just curious on the following questions: > > (1) What's the situation of the DDoS attack nowadays? Is spoofing of > source address still a major reason for the DDoS attack? I guess you meant 'still a major part', which it seems not be. Most DDoS attacks are simply mounted using a very large amount of real live hosts. A couple of years ago, when the predominant part of the attacks was source based, the attacks where mostly for 'fun' and simply annoying people, thus mostly attacks targeted at individuals. Now with 'organized' (ahem) crime intervening, as there is money to be made from it or at least crippling of the competition thus costing them money, the attacks are targeted more at businesses and not at a sole person. Though of course there will always be person-to-person fights. > (2) If most of DDoS attack has shift from using spoofing of source address to > using botnets, why such shift happens? > I suppose two reasons: > 1) Ingress filter has been deployed in many ISPs, and attacker feel it's > hard to launch such attack now. > 2) It's easier to launch attack with botnets than with spoofed source address. > But I am not sure about it. The ingress filtering solved part of the problem, but the real item is really that it is much more reliable to use non-spoofed addresses. Especially as botnets average around 500k hosts for the larget botnetwors, it is so easy to cripple a network that they really can't be bothered trying to figure out if a network is allowing spoofed addresses or not. That said, there is still a large amount of spoofed packets flying over the internet, currently most of these can be seen as UDP packets from Bogon address space (see http://www.cymru.com) source port 0, destination port 1025 or 1026, which usually has the Messenger Service on Windows bound to it, size around 480 bytes. Far from a DDoS but quite annoying for people without proper firewalls ;) SMB scans (port 137-139) are also quite normal it seems. See the Internet Storm Center (http://isc.sans.org) for more of those. > (3) Is it easier to handle DDoS attack if the source address in the packet > is authentic? Yes, because one doesn't need to figure out which source is really sending it. Filtering those prefixes thus becomes easier. But, the volume and amount of different hosts is so vast that one has to block a large amount of hosts to block them all. Also when those hosts are blocked, the next botnet is already in place to continue the attack. It depends a bit on the reason of the attack. If the attack is really for monetary gain, mostly for extortion nowadays, then the attacks will last till the money is transfered (and the bank + cops follow the money trail ;). These attacks will continue till they either give up or get caught. Also a very interesting new trend is to use protocol 41 tunnels (IPv6 in IPv4) as a covert channel, or even as a way to inject packets into tunnel streams. Protocol-41 gets ignored by many firewall products and can be spoofed exceptionally well when a misconfigured tunneling router is found (and there are too many of those apparently). Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060118/f4e789b3/signature.bin From zm at cernet.edu.cn Tue Jan 17 17:41:09 2006 From: zm at cernet.edu.cn (Zhang Miao) Date: Wed, 18 Jan 2006 09:41:09 +0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address Message-ID: Hi, Jeroen thanks a lot for your answers. I just want to add one more question: How to evaluate the situation of spoofing of source address in the current Internet? 1) Is it a big requirement that the source address of the packet should be authentic? first, is it the spoofing of source address a serious problem for the current Internet. Second, considering the possible investment to provide source address validation, e.g., deploying ingress filter, is it worth to make such investment? 2) Is current deployed mechanisms (mainly ingress filtering, and uRPF) working well enough? Shall we design and depoloy other mechanisms to do source address validation in the Internet? Here are some works in recent years. I want to get answers from more people. [1] Beverly, R. and S. Bauer, "The spoofer project: inferring the extent of source address filtering on the Internet", USENIX SRUTI 2005, 2005. [2] Bremler-Barr, A. and H. Levy, "Spoofing Prevention Method", IEEE Infocom 2005, 2005. [3] Park, K. and H. Lee, "On the Effectiveness of Route-Based Packet Filtering for Distributed DoS Attack Prevention in Power-Law Internets", ACM Sigcomm 2001, 2001. [4] Li, J., Mirkovic, J., Wang, M., Reiher, P., and L. Zhang, "SAVE: Source Address Validity Enforcement Protocol", IEEE Infocom 2002, 2002. thanks Miao -------Original Message ------------------------------------- From: "Jeroen Massar" To: "zm at cernet.edu.cn" Sent: 2006-01-18 09:15:00 Subject: Re: [e2e] DDoS attack vs. Spoofing of Source Address >Zhang Miao wrote: >> Hi, >> >> I just have a question related to DDoS Attack and Spoofing of Source Address. >> >> It was common for the DDoS attack to utilize the spoofed source address >> two years ago. And many people told me, it is botnets the main way >> to launch DDoS attack, in which source address is not spoofed. >> >> I'm just curious on the following questions: >> >> (1) What's the situation of the DDoS attack nowadays? Is spoofing of >> source address still a major reason for the DDoS attack? > >I guess you meant 'still a major part', which it seems not be. Most DDoS > attacks are simply mounted using a very large amount of real live hosts. > >A couple of years ago, when the predominant part of the attacks was >source based, the attacks where mostly for 'fun' and simply annoying >people, thus mostly attacks targeted at individuals. Now with >'organized' (ahem) crime intervening, as there is money to be made from >it or at least crippling of the competition thus costing them money, the >attacks are targeted more at businesses and not at a sole person. Though >of course there will always be person-to-person fights. > >> (2) If most of DDoS attack has shift from using spoofing of source address to >> using botnets, why such shift happens? >> I suppose two reasons: >> 1) Ingress filter has been deployed in many ISPs, and attacker feel it's >> hard to launch such attack now. >> 2) It's easier to launch attack with botnets than with spoofed source address. >> But I am not sure about it. > >The ingress filtering solved part of the problem, but the real item is >really that it is much more reliable to use non-spoofed addresses. >Especially as botnets average around 500k hosts for the larget >botnetwors, it is so easy to cripple a network that they really can't be >bothered trying to figure out if a network is allowing spoofed addresses >or not. > >That said, there is still a large amount of spoofed packets flying over >the internet, currently most of these can be seen as UDP packets from >Bogon address space (see http://www.cymru.com) source port 0, >destination port 1025 or 1026, which usually has the Messenger Service >on Windows bound to it, size around 480 bytes. Far from a DDoS but quite >annoying for people without proper firewalls ;) SMB scans (port 137-139) >are also quite normal it seems. See the Internet Storm Center >(http://isc.sans.org) for more of those. > >> (3) Is it easier to handle DDoS attack if the source address in the packet >> is authentic? > >Yes, because one doesn't need to figure out which source is really >sending it. Filtering those prefixes thus becomes easier. >But, the volume and amount of different hosts is so vast that one has to >block a large amount of hosts to block them all. Also when those hosts >are blocked, the next botnet is already in place to continue the attack. > >It depends a bit on the reason of the attack. If the attack is really >for monetary gain, mostly for extortion nowadays, then the attacks will >last till the money is transfered (and the bank + cops follow the money >trail ;). These attacks will continue till they either give up or get >caught. > >Also a very interesting new trend is to use protocol 41 tunnels (IPv6 in >IPv4) as a covert channel, or even as a way to inject packets into >tunnel streams. Protocol-41 gets ignored by many firewall products and >can be spoofed exceptionally well when a misconfigured tunneling router >is found (and there are too many of those apparently). > >Greets, > Jeroen = = = = = = = = = = = = = = = = = = = = ***************************************************************** * Zhang Miao * * Ph.D, Assistant Professor, Network Research Center * * Tsinghua University,Beijing,China(100084) * * Tel: (8610)-62795818-6271 * * Email: zm at cernet.edu.cn * * Web: http://netarchlab.tsinghua.edu.cn/~zm * ***************************************************************** From jeroen at unfix.org Tue Jan 17 18:11:07 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 18 Jan 2006 03:11:07 +0100 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: References: Message-ID: <43CDA3BB.3070305@unfix.org> Zhang Miao wrote: > Hi, Jeroen > > thanks a lot for your answers. > > I just want to add one more question: > > How to evaluate the situation of spoofing of source address in the > current Internet? > > 1) Is it a big requirement that the source address of the packet should > be authentic? Depends completely on what purpose one is using a network for. If one doesn't require any communication to be sent back to the source address then it doesn't have to be, neither if one doesn't assume any validity based on this address. But then one could do without the source address completely too. If one depends on the source address to be also the sender of the packet one is receiving then it is almost crucial to be able to make this assertion. Mechanisms like IPSEC can help out to solve this part of the puzzle though. > first, is it the spoofing of source address a serious problem for the > current Internet. The biggest issue with spoofed addresses is that it doesn't allow one to find the culprit easily who is sending these packets, unless doing some digging. Especially when sending a small volume of small packets, tracing them down to the real origin becomes a hard task, even more when operators are not available, pre-occupied with other problems or when there are language or political barriers. Transit providers for instance will help you out to resolve these issues, though it would be in their interest to actually deliver these packets as you are paying for them. There are also places where spoofed packets can be handy, especially for research, eg: http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-disco.pdf Where injecting packets from spoofed addresses, which are the tunnel endpoints, can be used to discover IPv6 tunnels, though one has to have a pre-knowledge of the tunnel endpoints in this case taken from the 6bone registry. The above method can also be used for not so nice tasks, as the source IP is the only security assertion for IPv6 tunnels (proto-41) one can easily abuse most 6to4 relays as an anonymous relay. Just send the spoofed packets and the relay will properly relay it and those packets are virtually untraceable. Having ingress filtering is a requirement for this setup to counter this problem. proto-41 tunneling could have been made more secure by using some security token, but this is nearly impossible especially as there is no global PKI, let alone one which can bootstrap automatically to be used by hosts without any intervention. > Second, considering the possible investment to provide source address > validation, e.g., deploying ingress filter, is it worth to make such > investment? The investment mostly comes in the form of hardware upgrades. Most hardware does support it, but it of course requires the correct version to do it. Some hardware can't do it at line rate and other implementations don't at all and thus need to be replaced completely to support it. There are few setups (eg satelite links) which have asymmetrical paths. In these cases one doesn't have to specifically define a filter, but a filter on the prefix from the up/downstream provider is already good enough. Filtering as close as possible to the origin is already great and usually inexpensive (cash, cpu and hardware wise) way to do this, it also limits the attack vector. Many ISP's though simply don't filter as they claim their hardware can't handle it. Others don't realize the importance until they get hit by a DDoS or other ISP's start depeering them because of their negligence. > 2) Is current deployed mechanisms (mainly ingress filtering, and uRPF) > working well enough? They work as long as the complete network uses them. When a trusted source is not using them the scheme falls over. At least in these cases one can trace it to this link based on traffic graphs, netflow data and other more 'expensive' sources. > Shall we design and deploy other mechanisms > to do source address validation in the Internet? uRPF and ingress filtering already suffice sufficiently. At the moment most DDoS attacks (afaik) are not using spoofing attacks any more due to the easy way to get a large amount of zombie hosts which can do damage easily and for a small price. The biggest requirement and wish list here is most likely to be able to convince network operators to actually implement and update these filters properly. One method that works quite well, but would still require that the packet is verified at every hop, which is something that was tried to be avoided in IPv6 and something which will not be done in general due to the computational overhead would be verifying IPSEC headers on every host. Having prefix filters is then a much much much cheaper method. > Here are some > works in recent years. I want to get answers from more people. Possibly an interesting related paper: http://www.caida.org/outreach/papers/2006/backscatter_dos/backscatter_dos.pdf CAIDA has a large number of good papers on this subject, thus you might want to look around on their site: http://www.caida.org/ Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060118/3f7d3e74/signature.bin From zm at cernet.edu.cn Tue Jan 17 18:38:07 2006 From: zm at cernet.edu.cn (Zhang Miao) Date: Wed, 18 Jan 2006 10:38:07 +0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address Message-ID: -------Original Message ------------------------------------- From: "Jeroen Massar" To: "zm at cernet.edu.cn" Sent: 2006-01-18 10:11:07 Subject: Re: [e2e] DDoS attack vs. Spoofing of Source Address >> 2) Is current deployed mechanisms (mainly ingress filtering, and uRPF) >> working well enough? > >They work as long as the complete network uses them. When a trusted >source is not using them the scheme falls over. At least in these cases >one can trace it to this link based on traffic graphs, netflow data and >other more 'expensive' sources. > >> Shall we design and deploy other mechanisms >> to do source address validation in the Internet? > >uRPF and ingress filtering already suffice sufficiently. At the moment >most DDoS attacks (afaik) are not using spoofing attacks any more due to >the easy way to get a large amount of zombie hosts which can do damage >easily and for a small price. The biggest requirement and wish list here >is most likely to be able to convince network operators to actually >implement and update these filters properly. As you said, ingress filter and uRFP "work as long as the complete network uses them". Also, one argue is that such mechanism is lack of incentive of deployment - the ISP that deploying the mechanism can only do good to other people, not themselves. So I'm just curious how to convince ALL ISPs to deploy them, from an economic aspect. We should set a "law" to ask all ISPs to deploy ingress fiter, or we should design some mechanisms (like SPM[1]) to provide enough incentive and can be incremental deployed? [1] Bremler-Barr, A. and H. Levy, "Spoofing Prevention Method", IEEE Infocom 2005, 2005. Greets, Miao ***************************************************************** * Zhang Miao * * Ph.D, Assistant Professor, Network Research Center * * Tsinghua University,Beijing,China(100084) * * Tel: (8610)-62795818-6271 * * Email: zm at cernet.edu.cn * * Web: http://netarchlab.tsinghua.edu.cn/~zm * ***************************************************************** From huitema at windows.microsoft.com Tue Jan 17 21:39:55 2006 From: huitema at windows.microsoft.com (Christian Huitema) Date: Tue, 17 Jan 2006 21:39:55 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <43CD9694.1050204@unfix.org> Message-ID: > > 2) If most of DDoS attack has shift from using spoofing of source > > address to using botnets, why such shift happens? > ... > > The ingress filtering solved part of the problem, but the real item is > really that it is much more reliable to use non-spoofed addresses. > Especially as botnets average around 500k hosts for the larget > botnetwors, it is so easy to cripple a network that they really can't be > bothered trying to figure out if a network is allowing spoofed addresses > or not. It is also much harder to defend the host against a non spoofed attack. The spoofed attacks have to be dumb: send single packets, don't expect a response, don't establish a session. Such single packets are relatively easy to filter. Even SYN packets can be dealt with efficiently. The attacker can thus only mount a bandwidth attack, trying to saturate the link to the server. This is doable, but requires a massive amount of traffic, which increases the chances of detection. On the other hand, if the address is not spoofed, the attack can mimick a completely authorized traffic, e.g. load the home page of "http://www.example.com/". You can do even better by loading a page that requires extensive computation, e.g. "https://www.example.com/". Let a botnet repeat that a few thousand times per second, and the server at "www.example.com" will start sweating bullets. -- Christian Huitema From Jon.Crowcroft at cl.cam.ac.uk Wed Jan 18 03:51:54 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 18 Jan 2006 11:51:54 +0000 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: Message from "Christian Huitema" of "Tue, 17 Jan 2006 21:39:55 PST." Message-ID: right- if you rent-a-bot farm , its a whole lot easier to script them with attacks that i) use the 0wned medchines real addresses and ii) use "normal" looking traffic... breaking either of these rules is going to make detecting the bot farm a whole lot easier which leads to it a) being closed down and b) potentially the bot-0wners being caught (esp. if their control traffic is traceable, which it sometimes is surprisingly easily... for info: there's a programme of work that UCL, Cambridge and MIT are engaged in looking at this whole space togther with folks from the London Internet Neutral Exchange and a lot of industry players (providers, router vendors, user companies - more info at http://www.communicationsresearch.net/dos-resistant/ two common defenses are ok for larger companies, but don't address the needs of smaller sites - putting your server on a load balanced site so that requests have to go via a proxy/front end that fans out the requests to many well provisioned servers, and the front end is itself on an overprovisioned link is one trick - essentially if you put such a redirector behind a 10Gbps link, few attacks can take it out, and it can normalise traffic and do a ferw other sdanity checks (supress or delay duplicaes etc) - doing this to your web service itself only (withotu redirector) and putting a hefty packet scrubber in front will mitigate things a bit but as you;'ve pointed out, with a "well formed" attack, it can't do so much various techniques to push back filters towards sources don't work fast enough for really large bot armies and someonewill eventally write something polymorphic enough trhat the traffic wil lbe well formed and a subset of real traffic in a manner that can't easily be filtered safely (to the real bot machines owner:) architectural changes to IP have been suggested but are hard to deploy near/medium term fixing host OSs so vulnerabilities are reduced or outbound traffic patterns is controlled through inverse firewall rules is also good detecting control traffic and pre-empting is a good thing legal and economic measures to create incentives to make OS vendor, host owner and isp owners take more care also contribute like spam, dos attacks are a complex problem space not amenable to point solutions, (at least not without turning off the usefuless of the internet:), but a raft of soultions are (anecdotally) making some headway against the problem recently slowly....of course its just an arms race... In missive , "Christian Huitema" typed: >>> > 2) If most of DDoS attack has shift from using spoofing of source >>> > address to using botnets, why such shift happens? >>> ... >>> >>> The ingress filtering solved part of the problem, but the real item is >>> really that it is much more reliable to use non-spoofed addresses. >>> Especially as botnets average around 500k hosts for the larget >>> botnetwors, it is so easy to cripple a network that they really can't >>be >>> bothered trying to figure out if a network is allowing spoofed >>addresses >>> or not. >> >>It is also much harder to defend the host against a non spoofed attack. >>The spoofed attacks have to be dumb: send single packets, don't expect a >>response, don't establish a session. Such single packets are relatively >>easy to filter. Even SYN packets can be dealt with efficiently. The >>attacker can thus only mount a bandwidth attack, trying to saturate the >>link to the server. This is doable, but requires a massive amount of >>traffic, which increases the chances of detection. >> >>On the other hand, if the address is not spoofed, the attack can mimick >>a completely authorized traffic, e.g. load the home page of >>"http://www.example.com/". You can do even better by loading a page that >>requires extensive computation, e.g. "https://www.example.com/". Let a >>botnet repeat that a few thousand times per second, and the server at >>"www.example.com" will start sweating bullets. >> >>-- Christian Huitema cheers jon From dpreed at reed.com Wed Jan 18 05:36:40 2006 From: dpreed at reed.com (David P. Reed) Date: Wed, 18 Jan 2006 08:36:40 -0500 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: References: Message-ID: <43CE4468.5090502@reed.com> I wonder if, on an open list like this one, we should be careful about discussing the relative effectiveness of DDoS attacks on current systems now deployed. I am sure there are those employed by various governments and revolutionary actors who are participants or lurkers here. My own government has declared itself no longer bound by its own laws and constitution in its exploitation of the Internet and communications systems against its own citizens. Joining many other actors, driven by extremism and ideology of all sorts, seeking power over others. So laws and social contracts are not currently working, and may not be workable, in the current international context. DDoS attacks of a sophisticated sort are like biological weapons - they can get out of control, cause persistent and permanent damage, amplifying a small effort into a large effect. It will take much ingenuity on the part of the human race to develop a way to coexist safely with such knowledge. I am not advocating "security by obscurity" here. In fact, I firmly believe in the exact opposite. Ultimately the science (of the artificial) that underlies decentralized resilience and robustness is a solution, and developing that science must occur in the open. But discussion of specific current vulnerability patterns *is* dangerous, just as giving out synthesis instructions for ebolavirus, and encouraging hackers all over the world to make a more virulent ebola, may be dangerous. However I don't (and we probably shouldn't) trust any agency of a government or any terrorist to be responsible at this point in time, especially if they are lurking here or we have no way to hold them to account as part of a community. Those of us who have some expertise in the area of decentralized and viral processes should be really thoughtful about where we share our knowledge of exploits... just as some of us, I am sure, would like to call back the naive decisions to deploy things like ActiveX and BrowserHelperObjects and javascript in email clients that were made without thinking about managing the risks. - David Zhang Miao wrote: >Hi, > >I just have a question related to DDoS Attack and Spoofing of Source Address. > >It was common for the DDoS attack to utilize the spoofed source address >two years ago. And many people told me, it is botnets the main way >to launch DDoS attack, in which source address is not spoofed. > >I'm just curious on the following questions: > >(1) What's the situation of the DDoS attack nowadays? Is spoofing of > source address still a major reason for the DDoS attack? > >(2) If most of DDoS attack has shift from using spoofing of source address to > using botnets, why such shift happens? > I suppose two reasons: > 1) Ingress filter has been deployed in many ISPs, and attacker feel it's > hard to launch such attack now. > 2) It's easier to launch attack with botnets than with spoofed source address. > But I am not sure about it. > >(3) Is it easier to handle DDoS attack if the source address in the packet > is authentic? > >I'm quite grateful to your answers. > >Miao > > >***************************************************************** >* Zhang Miao * >* Ph.D, Assistant Professor, Network Research Center * >* Tsinghua University,Beijing,China(100084) * >* Tel: (8610)-62795818-6271 * >* Email: zm at cernet.edu.cn * >* Web: http://netarchlab.tsinghua.edu.cn/~zm * >***************************************************************** > > > > > From rishi_jethwa at hotmail.com Wed Jan 18 07:09:14 2006 From: rishi_jethwa at hotmail.com (rishi jethwa) Date: Wed, 18 Jan 2006 15:09:14 +0000 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: Message-ID: Hi there, Since I did my Thesis in preventing DoS n DDoS attacks I would like to add my comments to this issue. First of all no attack is complete and no defense mechanism is complete. The most prevalent attacking category as of today is one that fits into packet flooding category. Even if the victim firewall or its first hop router has all the intelligence of the universe to defeat DoS n DDoS attacks, at one stage it will not be able to cop up with the attacker's floods intensity. All the attacker has to do is to increase the intensity. I mean to say if thousands of people arrive at the local drug store asking for bread, at one stage it will be impossible for a legitimate user to get asprin. 1) Is it a big requirement that the source address of the packet should be authentic? A) In his paper on TCP/IP weakness Moris said that the main weakness of this protocol is that the source host itself fills the source address and there is no provision in TCP/IP protocol stack to validate it. This spoofing and DoS problem would be completely solved if all the routers in the internet would employ ingress filtering. But as of now there is no general consensus on employing ingress filtering. All they want is to concentrate on effciency of moving packets. 2) Is current deployed mechanisms (mainly ingress filtering, and uRPF) working well enough? A) If all the routers in the internet would employ ingress filtering, DoS attacks can be mitigated. Also the router can now easily identify the source of the attack and stop it from doing that. I have no idea what uRPF is. 3)1) What's the situation of the DDoS attack nowadays? Is spoofing of source address still a major reason for the DDoS attack? A) The computer industry has made a lot of advancement in combating DoS attack but at the same time even the attackers are geting more sophisticated. Yes, spoofing is the main reason for the presense of DoS attack. Also when the attacker spoofs the source address they do not use the same address, I mean if they send 1000 packets, all or many of them would have different IP address, making it difficult for the Victim router or firewall to block any particular IP address. Also even if I know that the flood is coming from this IPaddress and even if I block it, but to block it I have to check it till LAYER 3 to see the IP address and then discard it. In doing so I have already spend my time n processing power, thats what attackers want. 4) If most of DDoS attack has shift from using spoofing of source address to using botnets, why such shift happens? A) if botnets u taking about is same as zombies, then see, the impact of the attack would be definately more if the flooding intensity is more. I have even read papers that describes the attack on some prominent webstite that has involved hundres of zombies. 5) Is it easier to handle DDoS attack if the source address in the packet is authentic? A) Even our SBC telephone network is not able to handle the traffic on mother's day. You got the answer? Every thing has a limit and maximum processing capability. If I can only serve 10 legitimate user per second and if 50 users are arriving per second, then its DoS for 40 of them. As I was talking all the attack wants is to overwhelm the victim firewall, router or subnet to such an extent that eventually no legitimate packet reaches the victim. And If I would be the attacker, I would prefer to use UDP traffic, which can do the same thing, eat up the bandwidth and processing power. My Thesis topic was "Sabotashing a Trusted Relationship: A Novel DoS attack". I have also proposed a reliable solution to defeat such attacks. My thesis report would answer all of your questions in detail. It also talks about the present attack types and techniques, current advancements made by the computer industry to defeat DoS attacks If you are interested contact me at rishi_jethwa at yahoo.com. Regards Rishi Jethwa Software Developer THUMBTECHS CORPORATION 8205 Camp Bowie W #110 Fort Worth, Texas 76116 817.923.2419 From rcarlson at internet2.edu Wed Jan 18 06:25:15 2006 From: rcarlson at internet2.edu (Richard Carlson) Date: Wed, 18 Jan 2006 09:25:15 -0500 Subject: [e2e] Call for Presentations Message-ID: <6.2.0.14.2.20060118085014.0418c3f0@mail.internet2.edu> Dear Colleague; Internet2 will be holding a 'Tools Tutorial' session at the upcoming Spring Member Meeting (April 24-26, 2006) in Arlington VA. The two major purposes for this session are (1) allow tool developers the opportunity to describe new tools that can be used to solve end-to-end performance problems; and (2) allow tool users the opportunity to describe how well tools work in their environment. Tools of interest include, but are not limited to; Active measurement tools Passive measurement tools Traffic analysis tools Simulation tools hop-by-hop measurement tools e2e path analysis tools New tools being developed Commercial tools Interested parties should send an email expressing their interest in participating to Richard Carlson by Feb 8, 2006. Up to three (3) presentations can be accommodated at this upcoming Member Meeting. Future Internet2 Member Meetings and ESCC/Joint Techs meetings may also have 'Tools Tutorial' session slots available. Schedule: Interest in participation: Feb 8, 06 Acceptance notice: Feb 22, 06 Meeting Dates: Mar 24-26, 06 URL: http://events.internet2.edu/2006/spring-mm/ Contact: Richard Carlson Respectfully; Rich Carlson ------------------------------------ Richard A. Carlson e-mail: RCarlson at internet2.edu Network Engineer phone: (734) 352-7043 Internet2 fax: (734) 913-4255 1000 Oakbrook Dr; Suite 300 Ann Arbor, MI 48104 From jtk at northwestern.edu Wed Jan 18 08:24:58 2006 From: jtk at northwestern.edu (John Kristoff) Date: Wed, 18 Jan 2006 10:24:58 -0600 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: References: Message-ID: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> On Wed, 18 Jan 2006 15:09:14 +0000 "rishi jethwa" wrote: > This spoofing and DoS problem would be completely solved > if all the routers in the internet would employ ingress filtering. This is simply not true. A great number of DoS attacks currently do not spoof their source address and even those that do often only spoof within the local /24 netblock. > But as of now there is no general consensus on employing ingress > filtering. All they want is to concentrate on effciency of moving > packets. Actually I think there is consensus that anti-spoof filtering is generally a good idea, but the reason it isn't ubiquitous is usually because of practical limitations (e.g. equipment support and complex network configurations). > A) If all the routers in the internet would employ ingress filtering, > DoS attacks can be mitigated. Also the router can now easily identify > the source of the attack and stop it from doing that. I have no idea > what uRPF is. With all due respect, for someone who did their thesis on DoS attacks, I am disappointed by your answers thus far. uRPF stands for unicast reverse path check. In a nutshell, when a packet arrives on an interface, if uRPF is enabled, the router can perform a check to verify whether the best (or in some configurations a feasible) path back to the source is back out that ingress interface. If it is, then the packet is allowed to be forwarded, otherwise it is filtered. > Yes, spoofing is the main reason for the presense of DoS attack. Again, not true. In, spoofing appears to have waned considerably over the past few years. Here is just one confirmation of that (see slide number 3): > My Thesis topic was "Sabotashing a Trusted Relationship: A Novel DoS > attack". I have also proposed a reliable solution to defeat such > attacks. Hmmm... John From rishi_jethwa at hotmail.com Wed Jan 18 09:27:29 2006 From: rishi_jethwa at hotmail.com (rishi jethwa) Date: Wed, 18 Jan 2006 17:27:29 +0000 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> Message-ID: Hi John, Majority of DoS attack that happens this days fits into packet flooding category. Today we donot have attack that uses some drawback in the protocol..like ping of death. If I properly secure my network, its very difficult for someone with just one system to have a DoS attack on me, no matter what combination of attack type he uses. So lets just talk about packet flooding category. N use DDoS instead of DoS. Even if you look at all the latest freely available DoS tools they all are sporting new capabilities that suits attack that fits into packet flooding category. And the attacker donot want there zombies to get caught, he would prefer to use randomly generated valid IP addresses. Regards Rishi From fergdawg at netzero.net Wed Jan 18 09:46:52 2006 From: fergdawg at netzero.net (Fergie) Date: Wed, 18 Jan 2006 17:46:52 GMT Subject: [e2e] DDoS attack vs. Spoofing of Source Address Message-ID: <20060118.094701.13667.63276@webmail46.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060118/77722414/attachment.ksh From touch at ISI.EDU Wed Jan 18 16:45:58 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 18 Jan 2006 16:45:58 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> Message-ID: <43CEE146.9040708@isi.edu> John Kristoff wrote: > On Wed, 18 Jan 2006 15:09:14 +0000 > "rishi jethwa" wrote: .... >> But as of now there is no general consensus on employing ingress >> filtering. All they want is to concentrate on effciency of moving >> packets. > > Actually I think there is consensus that anti-spoof filtering is > generally a good idea, but the reason it isn't ubiquitous is usually > because of practical limitations (e.g. equipment support and complex > network configurations). One practical limit is that ingress filtering works only if every router can be trusted to participate. Routers that do not are places where the traffic can enter, after which point ingress filtering won't help (for that traffic). The lack of a trusted ubiquitous deployment is the reason it isn't a good solution, which is further why it isn't ubiquitous (a bit of a catch-22). ... >> Yes, spoofing is the main reason for the presense of DoS attack. > > Again, not true. In, spoofing appears to have waned considerably > over the past few years. Here is just one confirmation of that (see > slide number 3): > > These slides refer to bogon traffic - with source addresses that are reserved (e.g. Martians) or unallocated. Spoofing a bogon address would not be useful (it can be trapped at any router); perhaps you meant some other slides? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060118/09bee5c3/signature.bin From touch at ISI.EDU Wed Jan 18 16:50:53 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 18 Jan 2006 16:50:53 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: References: Message-ID: <43CEE26D.1010301@isi.edu> rishi jethwa wrote: > Hi John, > > Majority of DoS attack that happens this days fits into packet flooding > category. Today we donot have attack that uses some drawback in the > protocol..like ping of death. See http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-02.txt It's not quite a ping of death, but it's not quite flooding either. I.e., the attack depends on covering a number space, not on the sheer volume of traffic emitted. > If I properly secure my network, its very difficult for someone with > just one system to have a DoS attack on me, no matter what combination > of attack type he uses. One system can knock out your system if you run IPsec, especially if on-path - by generating spoofed traffic with the right SPI with the wrong key. The result sends your CPU into overload verifying that the packets are badly encrypted. (this presumes you're using software for encryption). Similar attacks should work for HTTPS and SSL (though someone else can help verify that this) by attempting connections with bad signature exchanges. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060118/73f8a499/signature.bin From jtk at northwestern.edu Wed Jan 18 18:12:40 2006 From: jtk at northwestern.edu (John Kristoff) Date: Wed, 18 Jan 2006 20:12:40 -0600 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <43CEE146.9040708@isi.edu> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> Message-ID: <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> On Wed, 18 Jan 2006 16:45:58 -0800 Joe Touch wrote: > These slides refer to bogon traffic - with source addresses that are > reserved (e.g. Martians) or unallocated. Spoofing a bogon address > would not be useful (it can be trapped at any router); perhaps you > meant some other slides? No I meant those. Spoofing is spoofing, regardless if it's bogons. Besides, you just earlier claimed, correctly, that ingress filtering only works if every router can be trusted to participate, but they can't and we have proof that many not so insignificant networks are forwarding spoofed packets. So bogon filtering can be just as useful to an attacker as an assigned and in-use spoofed address. :-) However, in my experience, the use of local /24 netblock spoofing is commonly used if packets are spoofed at all. I guess I needed to stipulate that these were bogons and that those slides indicated that bogon spoofing was on the wane. I couldn't think of any other publicly available resource that documented spoofing in general has declined, but in my experience and in talking with other operators, I believe in general it has. I would venture to guess that the percentage in that slide is probably accurate not just for bogon spoofing statistics, but spoofing in general. That is, less than 20% or even less than 15% of attacks these days are spoofing addresses. It may be more interesting that attackers don't bother spoofing more. The explanation is relatively simple though, they don't really need to. DoS agents are a dime a dozen, literally. It's a shame why they don't need to, but it highlights the diminishing marginal returns of fixing spoofing. John From touch at ISI.EDU Thu Jan 19 09:43:23 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 19 Jan 2006 09:43:23 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> Message-ID: <43CFCFBB.20507@isi.edu> John Kristoff wrote: > On Wed, 18 Jan 2006 16:45:58 -0800 > Joe Touch wrote: > >> These slides refer to bogon traffic - with source addresses that are >> reserved (e.g. Martians) or unallocated. Spoofing a bogon address >> would not be useful (it can be trapped at any router); perhaps you >> meant some other slides? > > No I meant those. Spoofing is spoofing, regardless if it's bogons. > Besides, you just earlier claimed, correctly, that ingress filtering > only works if every router can be trusted to participate, but they > can't and we have proof that many not so insignificant networks are > forwarding spoofed packets. So bogon filtering can be just as useful > to an attacker as an assigned and in-use spoofed address. :-) Bogon filtering is special; there are no routers for which bogons should be forwarded at all. They can be trapped anywhere in the network as a result. However, spoofed traffic from A to B can be trapped only at routers that should never forward traffic from A (i.e., the diverting source 'branch'). Once that traffic enters the A-B path, no router on the remainder of that path can distinguish A from fake-A by address alone, and so cannot drop the traffic. The two cases are very different as a result. Further, no attacker would intentionally spoof bogons; they can and should be dropped already. Bogons reflect incorrect configuration, typically accidental or erroneous, rather than deliberate. The statistics of bogon traffic do not correlate to the statistics of spoofed. > However, in my experience, the use of local /24 netblock spoofing is > commonly used if packets are spoofed at all. > > I guess I needed to stipulate that these were bogons and that those > slides indicated that bogon spoofing was on the wane. The slides do not talk about spoofing. The talk about bogon traffic. The slides cite another talk that asserts that DOS attacks come from bogon addresses - but that's not the same thing as spoofing. Even that talk does not explain why this traffic is considered an attack. It's entirely possible that the traffic is accidental, and results in a DOS attack on resources. That is NOT the same as a spoofing attack. > I couldn't > think of any other publicly available resource that documented spoofing > in general has declined, but in my experience and in talking with other > operators, I believe in general it has. I would venture to guess that > the percentage in that slide is probably accurate not just for bogon > spoofing statistics, but spoofing in general. That is, less than > 20% or even less than 15% of attacks these days are spoofing addresses. It is not useful to extrapolate statistics here; guessing that they would be useful in this case is as accurate as picking a number at random. If someone has real statistics, that'd be useful, however. > It may be more interesting that attackers don't bother spoofing more. > The explanation is relatively simple though, they don't really need > to. DoS agents are a dime a dozen, literally. It's a shame why they > don't need to, but it highlights the diminishing marginal returns of > fixing spoofing. Spoofing is useful only where it is of benefit to masquerade as another IP address; that's a tautology, though. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060119/da2b1508/signature.bin From mbaugher at cisco.com Thu Jan 19 10:23:08 2006 From: mbaugher at cisco.com (Mark Baugher) Date: Thu, 19 Jan 2006 10:23:08 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <43CE4468.5090502@reed.com> References: <43CE4468.5090502@reed.com> Message-ID: On Jan 18, 2006, at 5:36 AM, David P. Reed wrote: > I wonder if, on an open list like this one, we should be careful about > discussing the relative effectiveness of DDoS attacks on current > systems > now deployed. To me, it seems important to discuss vulnerabilities and news of exploits with describing publicly how to exploit vulnerabilities. Otherwise, it's like keeping the fact that the government is tapping the conversations of its citizens secret when any competent criminal would assume that in the first place. Mark > > I am sure there are those employed by various governments and > revolutionary actors who are participants or lurkers here. > > My own government has declared itself no longer bound by its own laws > and constitution in its exploitation of the Internet and > communications > systems against its own citizens. Joining many other actors, driven by > extremism and ideology of all sorts, seeking power over others. So > laws > and social contracts are not currently working, and may not be > workable, > in the current international context. > > DDoS attacks of a sophisticated sort are like biological weapons - > they > can get out of control, cause persistent and permanent damage, > amplifying a small effort into a large effect. It will take much > ingenuity on the part of the human race to develop a way to coexist > safely with such knowledge. > > I am not advocating "security by obscurity" here. In fact, I firmly > believe in the exact opposite. Ultimately the science (of the > artificial) that underlies decentralized resilience and robustness > is a > solution, and developing that science must occur in the open. But > discussion of specific current vulnerability patterns *is* dangerous, > just as giving out synthesis instructions for ebolavirus, and > encouraging hackers all over the world to make a more virulent ebola, > may be dangerous. > > However I don't (and we probably shouldn't) trust any agency of a > government or any terrorist to be responsible at this point in time, > especially if they are lurking here or we have no way to hold them to > account as part of a community. Those of us who have some expertise in > the area of decentralized and viral processes should be really > thoughtful about where we share our knowledge of exploits... just as > some of us, I am sure, would like to call back the naive decisions to > deploy things like ActiveX and BrowserHelperObjects and javascript in > email clients that were made without thinking about managing the > risks. > > - David > > Zhang Miao wrote: > >> Hi, >> >> I just have a question related to DDoS Attack and Spoofing of >> Source Address. >> >> It was common for the DDoS attack to utilize the spoofed source >> address >> two years ago. And many people told me, it is botnets the main way >> to launch DDoS attack, in which source address is not spoofed. >> >> I'm just curious on the following questions: >> >> (1) What's the situation of the DDoS attack nowadays? Is spoofing of >> source address still a major reason for the DDoS attack? >> >> (2) If most of DDoS attack has shift from using spoofing of source >> address to >> using botnets, why such shift happens? >> I suppose two reasons: >> 1) Ingress filter has been deployed in many ISPs, and attacker >> feel it's >> hard to launch such attack now. >> 2) It's easier to launch attack with botnets than with spoofed >> source address. >> But I am not sure about it. >> >> (3) Is it easier to handle DDoS attack if the source address in >> the packet >> is authentic? >> >> I'm quite grateful to your answers. >> >> Miao >> >> >> ***************************************************************** >> * Zhang Miao * >> * Ph.D, Assistant Professor, Network Research Center * >> * Tsinghua University,Beijing,China(100084) * >> * Tel: (8610)-62795818-6271 * >> * Email: zm at cernet.edu.cn * >> * Web: http://netarchlab.tsinghua.edu.cn/~zm * >> ***************************************************************** >> >> >> >> >> From jtk at northwestern.edu Thu Jan 19 11:33:31 2006 From: jtk at northwestern.edu (John Kristoff) Date: Thu, 19 Jan 2006 13:33:31 -0600 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <43CFCFBB.20507@isi.edu> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> <43CFCFBB.20507@isi.edu> Message-ID: <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> On Thu, 19 Jan 2006 09:43:23 -0800 Joe Touch wrote: > Further, no attacker would intentionally spoof bogons; Many DoS agents have had the ability to randomly fake the source address and of course they commonly come up with a "bogon". Agents sometimes also have the capability to fake the source address within some variable length netmask. I guess if attackers really cared about the "quality" of their faked sources they probably wouldn't want use a bogon, but they don't really need to care as I mentioned earlier so sometimes you do see it. John From touch at ISI.EDU Thu Jan 19 12:23:27 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 19 Jan 2006 12:23:27 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> <43CFCFBB.20507@isi.edu> <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> Message-ID: <43CFF53F.6000207@isi.edu> John Kristoff wrote: > On Thu, 19 Jan 2006 09:43:23 -0800 > Joe Touch wrote: > >> Further, no attacker would intentionally spoof bogons; > > Many DoS agents have had the ability to randomly fake the source > address and of course they commonly come up with a "bogon". Sure. That sounds more like a bug in their source address checking code, IMO. > Agents sometimes also have the capability to fake the source address > within some variable length netmask. I guess if attackers really > cared about the "quality" of their faked sources they probably > wouldn't want use a bogon, but they don't really need to care as I > mentioned earlier so sometimes you do see it. They would care if they really cared about hiding; sourcing bogons is a fairly clear indication that something is wrong - intentional or not. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060119/7741435c/signature.bin From jtk at northwestern.edu Thu Jan 19 13:55:46 2006 From: jtk at northwestern.edu (John Kristoff) Date: Thu, 19 Jan 2006 15:55:46 -0600 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <43CFF53F.6000207@isi.edu> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> <43CFCFBB.20507@isi.edu> <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> <43CFF53F.6000207@isi.edu> Message-ID: <20060119215546.GA2833@aharp> On Thu, Jan 19, 2006 at 12:23:27PM -0800, Joe Touch wrote: > > Many DoS agents have had the ability to randomly fake the source > > address and of course they commonly come up with a "bogon". > > Sure. That sounds more like a bug in their source address checking code, > IMO. If I was to think as an attacker, why would I spend my effort writing perfect spoofing code when it is clearly not necessary for my attacks to be effective. Likewise, if I'm one trying to mitigate the attacks, why would I focus on trying to stop spoofing? John From touch at ISI.EDU Thu Jan 19 16:46:42 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 19 Jan 2006 16:46:42 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <20060119215546.GA2833@aharp> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> <43CFCFBB.20507@isi.edu> <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> <43CFF53F.6000207@isi.edu> <20060119215546.GA2833@aharp> Message-ID: <43D032F2.6090705@isi.edu> John Kristoff wrote: > On Thu, Jan 19, 2006 at 12:23:27PM -0800, Joe Touch wrote: > >>> Many DoS agents have had the ability to randomly fake the source >>> address and of course they commonly come up with a "bogon". >> Sure. That sounds more like a bug in their source address checking code, >> IMO. > > If I was to think as an attacker, why would I spend my effort writing > perfect spoofing code when it is clearly not necessary for my attacks > to be effective. If you 'slip' and generate bogons, and because of that your attack is more readily detected, you have been less effective. > Likewise, if I'm one trying to mitigate the attacks, > why would I focus on trying to stop spoofing? That depends entirely on whether spoofing or the DOS attack itself are easier to detect. Some DOS attacks are isomorphic to flash crowds; in those cases, if there is no spoofing, the best you can do is shed load gracefully anyway. If the DOS attack is otherwise detectable as an attack per se, you shed it preferentially. The question is whether that detection is based on "this is spoofed" or based on some other property of the traffic (i.e., too many users asking for a particular file, too many SYNs that don't reply to SYN/ACKs, etc.) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060119/ab7db281/signature.bin From jtk at northwestern.edu Thu Jan 19 17:31:29 2006 From: jtk at northwestern.edu (John Kristoff) Date: Thu, 19 Jan 2006 19:31:29 -0600 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <115B8F4F-7BB6-4352-B9F7-68B777BBFEC7@cisco.com> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> <43CFCFBB.20507@isi.edu> <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> <43CFF53F.6000207@isi.edu> <20060119215546.GA2833@aharp> <115B8F4F-7BB6-4352-B9F7-68B777BBFEC7@cisco.com> Message-ID: <20060120013128.98DD2136C82@aharp.ittns.northwestern.edu> On Thu, 19 Jan 2006 16:43:23 -0800 Fred Baker wrote: > Your first point is valid, but yet we see spoofing in the network - > less than a while back, but still a lot. Ingress Filtering has value > in limiting spoofing, and while yes it helps the customers of other > networks, it also helps the customers of my network, which I will > argue is my incentive to deploy it. In limiting spoofing, I partially > mitigate certain classes of attacks as close to their source as I can > put it. Darn it, I knew someone was going to say something like that as if I think limiting spoofing in general is a waste of time. That is not the message I intended to convey. Limiting is good and it does help. I'm a supporter of it and I do it rigorously in networks I help run (and let me tell you how much of a pain it is to manage for multicast service some time). However, it is not going to make most of the DoS attacks seen today go away one bit. John From touch at ISI.EDU Fri Jan 20 08:49:56 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 20 Jan 2006 08:49:56 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <20060120013128.98DD2136C82@aharp.ittns.northwestern.edu> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> <43CFCFBB.20507@isi.edu> <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> <43CFF53F.6000207@isi.edu> <20060119215546.GA2833@aharp> <115B8F4F-7BB6-4352-B9F7-68B777BBFEC7@cisco.com> <20060120013128.98DD2136C82@aharp.ittns.northwestern.edu> Message-ID: <43D114B4.1030101@isi.edu> John Kristoff wrote: > On Thu, 19 Jan 2006 16:43:23 -0800 > Fred Baker wrote: > >> Your first point is valid, but yet we see spoofing in the network - >> less than a while back, but still a lot. Ingress Filtering has value >> in limiting spoofing, and while yes it helps the customers of other >> networks, it also helps the customers of my network, which I will >> argue is my incentive to deploy it. In limiting spoofing, I partially >> mitigate certain classes of attacks as close to their source as I can >> put it. > > Darn it, I knew someone was going to say something like that as if > I think limiting spoofing in general is a waste of time. That is > not the message I intended to convey. Limiting is good and it does > help. I'm a supporter of it and I do it rigorously in networks I > help run (and let me tell you how much of a pain it is to manage for > multicast service some time). However, it is not going to make most > of the DoS attacks seen today go away one bit. > > John I tend to agree - the issue with ingress filtering is that: for stubs: it helps ensure that hosts on your stub are playing nice and not spoofing addresses outside your stub for intechanges: it helps ensure that your interchange doesn't propagate traffic spoofed from elsewhere I.e., it basically makes sure YOU follow the rules; it says nothing about what others do. While it's certainly appropriate to install such filters, trusting them is not an option, since the filters you would really need to trust aren't under your control. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060120/ce19a01b/signature.bin From fred at cisco.com Thu Jan 19 16:43:23 2006 From: fred at cisco.com (Fred Baker) Date: Thu, 19 Jan 2006 16:43:23 -0800 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <20060119215546.GA2833@aharp> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> <43CFCFBB.20507@isi.edu> <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> <43CFF53F.6000207@isi.edu> <20060119215546.GA2833@aharp> Message-ID: <115B8F4F-7BB6-4352-B9F7-68B777BBFEC7@cisco.com> Your first point is valid, but yet we see spoofing in the network - less than a while back, but still a lot. Ingress Filtering has value in limiting spoofing, and while yes it helps the customers of other networks, it also helps the customers of my network, which I will argue is my incentive to deploy it. In limiting spoofing, I partially mitigate certain classes of attacks as close to their source as I can put it. Note that managing ddos attacks is never a matter of applying one golden tool and suddenly they all go away; rather, we identify high percentage solutions to specific attacks ("gee, this ddos seems to be a whole lot of folks starting to download the home page and then going away; lets change the URL of the web page and reply to the download request with a simple response that redirects the requester to it. Maybe the bogons won't follow.") and apply them. I don't see people focusing on spoofing per se. I do see them using anti-spoof measures as one of the armaments in their arsenal. On Jan 19, 2006, at 1:55 PM, John Kristoff wrote: > On Thu, Jan 19, 2006 at 12:23:27PM -0800, Joe Touch wrote: > >>> Many DoS agents have had the ability to randomly fake the source >>> address and of course they commonly come up with a "bogon". >> >> Sure. That sounds more like a bug in their source address checking >> code, >> IMO. > > If I was to think as an attacker, why would I spend my effort writing > perfect spoofing code when it is clearly not necessary for my attacks > to be effective. Likewise, if I'm one trying to mitigate the attacks, > why would I focus on trying to stop spoofing? > > John From rbeverly at rbeverly.net Mon Jan 23 13:04:55 2006 From: rbeverly at rbeverly.net (Robert Beverly) Date: Mon, 23 Jan 2006 16:04:55 -0500 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <20060118.094701.13667.63276@webmail46.lax.untd.com> References: <20060118.094701.13667.63276@webmail46.lax.untd.com> Message-ID: <20060123210454.GA30689@rbeverly.net> On Wed, Jan 18, 2006 at 05:46:52PM +0000, Fergie wrote: > It is difficult, if mot impossible, to determine the extent to > which BCP38 is delpoyed -- even though its deployment should be > encouraged. > > [2] Rob Beverly is/was the catalyst behind the Spoofer Project to > determine the extent to which this was deployed. either at the > network ingress or at the host level: We've collected nearly 1200 unique reports from around the Internet and have an interesting, if not completely representative, dataset. One particular new feature of the spoofer tester is the ability to determine where along a tested path filtering is employed with what we're calling a "reverse traceroute" mechanism [1]. Knowing the "filtering depth" is of particular interest to us since there is an operational tension between the specificity of router-level filters and the ability to properly maintain them. We also test fun stuff such as how far into the adjacent neighbor address space the client can spoof, filtering inconsistencies, etc. We'd appreciate any runs of the spoofer tester to help us gather additional data. The client, more details of the reverse traceroute as well as our "state of IP spoofing" summary results are all the web page: http://spoofer.csail.mit.edu/ Thanks, rob [1] The idea for the reverse traceroute arose from a fruitful discussion with John Curran. From gaylord at dirtcheapemail.com Thu Jan 26 05:57:17 2006 From: gaylord at dirtcheapemail.com (Clark Gaylord) Date: Thu, 26 Jan 2006 08:57:17 -0500 Subject: [e2e] DDoS attack vs. Spoofing of Source Address In-Reply-To: <115B8F4F-7BB6-4352-B9F7-68B777BBFEC7@cisco.com> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43CEE146.9040708@isi.edu> <20060119021242.1AE20136C82@aharp.ittns.northwestern.edu> <43CFCFBB.20507@isi.edu> <20060119193331.EDE19136C82@aharp.ittns.northwestern.edu> <43CFF53F.6000207@isi.edu> <20060119215546.GA2833@aharp> <115B8F4F-7BB6-4352-B9F7-68B777BBFEC7@cisco.com> Message-ID: <1138283837.21116.252818037@webmail.messagingengine.com> On Thu, 19 Jan 2006 16:43:23 -0800, "Fred Baker" said: > argue is my incentive to deploy it. In limiting spoofing, I partially > mitigate certain classes of attacks as close to their source as I can > put it. I want this all the way to the host port. Some implement this with DHCP snooping. This is fine in the 0.01% of the cases where this method is deployable and effective. ARP snooping is better, but still just another bolt to throw into our big old bucket of bolts. The issue is, how can we throw out the bucket? I have some ideas here, but don't have enough space in the margin of this book. This will be discussed at JointTechs, for those who will be there. --ckg -- Clark Gaylord Blacksburg, VA USA gaylord at dirtcheapemail.com From baruch at ev-en.org Thu Jan 26 11:16:34 2006 From: baruch at ev-en.org (Baruch Even) Date: Thu, 26 Jan 2006 19:16:34 +0000 Subject: [e2e] H-TCP bug in Linux Message-ID: <43D92012.2050006@ev-en.org> Hi, There is a bug in the Linux implementation of H-TCP so the current implementation in Linux does not reflect on the H-TCP protocol as designed. If you are doing tests on H-TCP it would be a good idea to apply the attached patch. The bug is in the kernels 2.6.13, .14 and .15. The patch was submitted to the netdev mailing list and will hopefully be part of the 2.6.16 kernel. Regards, Baruch -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: htcp_incorrect_count Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060126/fea86cef/htcp_incorrect_count.ksh From chvogt at tm.uka.de Mon Jan 30 13:59:10 2006 From: chvogt at tm.uka.de (Christian Vogt) Date: Mon, 30 Jan 2006 22:59:10 +0100 Subject: [e2e] Redirection-Based Flooding Attacks (was Re: DDoS attack vs. Spoofing of Source Address) In-Reply-To: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> Message-ID: <43DE8C2E.4090805@tm.uka.de> Everybody, a typical issue with mobility protocols such as Mobile IPv6 [1] or the Host Identity Protocol's mobility extensions [2] is that they potentially introduce a new form of flooding attack: redirection-based flooding attacks. In waging a redirection-based flooding attack, the perpetrator uses its own IP address to request the download of a large file, e.g., through a TCP handshake. Once the server begins transmitting this file, the attacker redirects the flow to the IP address of its victim, pretending to be mobile and to now be reachable via the victim's IP address. Depending on the mobility protocol, ingress filtering may keep the redirector from sending the redirection request (in particular, if the new IP address appears the IPv6 header's Source Address field). In any case, ingress filtering cannot stop the redirected packets, however, because their source addresses are correct. Also depending on the mobility protocol, the victim may or may not be able to identify the redirector based on information in the packets that it is impelled to receive. E.g., in Mobile IPv6, a verified, stable IP address of the redirector---the so-called "home address"---is present in all redirected packets, whereas the Host Identity Protocol does not have a feature like this. However, the hint on the redirector is usually of little benefit anyway, as it may only identify a zombie, not the actual attacker. The issue with redirection-based flooding attacks is solved by reachability checks, or "return-routability checks", as they have been named within the IETF: When a mobile node requests a packet flow to be redirected to a new IP address, its peer verifies whether there is indeed someone willing to receive the packets at that new IP address. The verification is quite simple: The peer sends an unguessable number to the new IP address and waits for this number to be echoed by the mobile node. Only then will the peer start to send packets to the new IP address. Of course, reachability tests take their time and have an impact on handoff performance. They thus compromise the quality of delay-sensitive real-time applications such as VoIP. But there are ways to make reachability verification concurrent in order to hide its latency. One can thus check a new IP address while this IP address is already being used---without loosing any of the security that (non-concurrent, blocking) reachability verification provides [2][3]. Best, - Christian [1] RFC 3775 [2] draft-ietf-hip-mm-02.txt [3] draft-vogt-mobopts-credit-based-authorization-00.txt -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ John Kristoff wrote: > On Wed, 18 Jan 2006 15:09:14 +0000 > "rishi jethwa" wrote: > > >>This spoofing and DoS problem would be completely solved >>if all the routers in the internet would employ ingress filtering. > > > This is simply not true. A great number of DoS attacks currently do > not spoof their source address and even those that do often only spoof > within the local /24 netblock. > > >>But as of now there is no general consensus on employing ingress >>filtering. All they want is to concentrate on effciency of moving >>packets. > > > Actually I think there is consensus that anti-spoof filtering is > generally a good idea, but the reason it isn't ubiquitous is usually > because of practical limitations (e.g. equipment support and complex > network configurations). > > >>A) If all the routers in the internet would employ ingress filtering, >>DoS attacks can be mitigated. Also the router can now easily identify >>the source of the attack and stop it from doing that. I have no idea >>what uRPF is. > > > With all due respect, for someone who did their thesis on DoS attacks, > I am disappointed by your answers thus far. > > uRPF stands for unicast reverse path check. In a nutshell, when a > packet arrives on an interface, if uRPF is enabled, the router can > perform a check to verify whether the best (or in some configurations > a feasible) path back to the source is back out that ingress interface. > If it is, then the packet is allowed to be forwarded, otherwise it is > filtered. > > >>Yes, spoofing is the main reason for the presense of DoS attack. > > > Again, not true. In, spoofing appears to have waned considerably > over the past few years. Here is just one confirmation of that (see > slide number 3): > > > >>My Thesis topic was "Sabotashing a Trusted Relationship: A Novel DoS >>attack". I have also proposed a reliable solution to defeat such >>attacks. > > > Hmmm... > > John From detlef.bosau at web.de Tue Jan 31 06:17:46 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 31 Jan 2006 15:17:46 +0100 Subject: [e2e] Redirection-Based Flooding Attacks (was Re: DDoS attack vs.Spoofing of Source Address) References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43DE8C2E.4090805@tm.uka.de> Message-ID: <43DF718A.47CD28D0@web.de> Christian Vogt wrote: > > Everybody, > > a typical issue with mobility protocols such as Mobile IPv6 [1] or the > Host Identity Protocol's mobility extensions [2] is that they > potentially introduce a new form of flooding attack: redirection-based > flooding attacks. > > In waging a redirection-based flooding attack, the perpetrator uses its > own IP address to request the download of a large file, e.g., through a > TCP handshake. Once the server begins transmitting this file, the > attacker redirects the flow to the IP address of its victim, pretending > to be mobile and to now be reachable via the victim's IP address. Yes. And because there exists no corresponding socket at the "victim", the sender will send one CWND worth full of data, see a number of timeouts and backoffs and eventually die. O.k., there may be a dozen annoying packets or so. And of course, there exist more convincing scenarios for your problem than just a TCP flow ;-) Despite of this, I?m not fully convinced of the relevance of Mobile IP and its descendendants. For me, the world consists of wirebound networks, mobile wide area networs (with their own L2 infrastructure and micromobility) and perhaps the one or the other leaf network which appears like an "IEEE....." network segment. Hence, I dont?t see a compelling reason for mobile IP. Of course, you mentioned a pontitial security problem in mobile IP. So, if something is not really necessary but raises a problem, one possible way out is to forget about this one:-) (Yes, of course, I know about the battlefield scenario.... However, when I look at actual battlefields, I?m not fully convinced that the lack of MANETs and mobile IP is the dominant problem there...) > > Of course, reachability tests take their time and have an impact on > handoff performance. They thus compromise the quality of > delay-sensitive real-time applications such as VoIP. But there are ways I don?t see any sense in VoIP over wireless networks. If you use VoIP in wirebound networks, which can make sense under certain conditions, you would direct a VoIP flow to a wireless terminal using a service that terminates the VoIP flow in the wirebound network and forwards the voice flow via an ordinary voice stream using the mobile networks TDM interface. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From chvogt at tm.uka.de Tue Jan 31 23:07:56 2006 From: chvogt at tm.uka.de (Christian Vogt) Date: Wed, 01 Feb 2006 08:07:56 +0100 Subject: [e2e] Redirection-Based Flooding Attacks (was Re: DDoS attack vs.Spoofing of Source Address) In-Reply-To: <43DF718A.47CD28D0@web.de> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43DE8C2E.4090805@tm.uka.de> <43DF718A.47CD28D0@web.de> Message-ID: <43E05E4C.1080806@tm.uka.de> Detlef, the attacker would have to send TCP acknowledgments in order to make the TCP sender assume that the packets go to the right IP address. If the mobility protocol allows only for a single address' registration, the TCP acknowledgments have to be spoofed. However, there are also protocols that allow a "mobile" or "multi-homed" node to register multiple addresses in parallel. In case the attacker uses such a protocol, it can send TCP acknowledgments from its own IP address and have the TCP sender ship its data segments to the victim's address. The Host Identity Protocol and, by definition, all multi-homing protocols (see, e.g., IETF's Shim working group) have this "multi-address" property. But there is actually another mechanism that can prevent such redirection-based flooding attacks: The victim does not know what to do with the received TCP segments, hence it will send an RST segment and cause the TCP sender to stop. In case you use a different transport protocol than TCP, ICMP Port Unreachable messages would typically be used instead. A RST segment's sequence number must fit into the TCP sender's receive window, otherwise the RST segment will be discarded. As Mark Doll mentioned in a private discussion, the attacker could exploit this by advancing the TCP sender's receive window fast enough so that the victim's RST segments won't have an effect. This is even easier for the attacker if the TCP sender implements the mechanisms specified in [1]. (The attacker would have to send data packets for this, however.) [1] draft-ietf-tcpm-tcpsecure-03.txt - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Detlef Bosau wrote: > Christian Vogt wrote: > >>Everybody, >> >>a typical issue with mobility protocols such as Mobile IPv6 [1] or the >>Host Identity Protocol's mobility extensions [2] is that they >>potentially introduce a new form of flooding attack: redirection-based >>flooding attacks. >> >>In waging a redirection-based flooding attack, the perpetrator uses its >>own IP address to request the download of a large file, e.g., through a >>TCP handshake. Once the server begins transmitting this file, the >>attacker redirects the flow to the IP address of its victim, pretending >>to be mobile and to now be reachable via the victim's IP address. > > > > Yes. And because there exists no corresponding socket at the "victim", > the sender will send one CWND worth full of data, > see a number of timeouts and backoffs and eventually die. > > O.k., there may be a dozen annoying packets or so. > > And of course, there exist more convincing scenarios for your problem > than just a TCP flow ;-) > > Despite of this, I?m not fully convinced of the relevance of Mobile IP > and its descendendants. For me, the world > consists of wirebound networks, mobile wide area networs (with their own > L2 infrastructure and micromobility) and perhaps > the one or the other leaf network which appears like an "IEEE....." > network segment. Hence, I dont?t see a compelling reason > for mobile IP. Of course, you mentioned a pontitial security problem in > mobile IP. So, if something is not really necessary > but raises a problem, one possible way out is to forget about this > one:-) > > (Yes, of course, I know about the battlefield scenario.... However, > when I look at actual battlefields, I?m not fully convinced > that the lack of MANETs and mobile IP is the dominant problem there...) > > >>Of course, reachability tests take their time and have an impact on >>handoff performance. They thus compromise the quality of >>delay-sensitive real-time applications such as VoIP. But there are ways > > > I don?t see any sense in VoIP over wireless networks. > > If you use VoIP in wirebound networks, which can make sense under > certain conditions, you would direct a VoIP flow to a wireless > terminal using a service that terminates the VoIP flow in the wirebound > network and forwards the voice flow via an ordinary voice stream > using the mobile networks TDM interface. > > Detlef