!white.house, !panacea, new traceback paper from stefan savage
(not sure if this has been posted yet, sorry if so) new relevant paper worth checking out by stefan savage et al (david, ann, tom, all UW) disclaimer, these folks just at the "explore the problem" stage and not the "propose a complete implementation now" stage. but exploring the problem is good From Stefan: On Thu, Feb 10, 2000 at 05:14:56PM -0800, Stefan Savage wrote: Hi KC, We've been doing some work on efficient network support for tracing denial-of-service attacks and all of a sudden the topic has some relevance (a strange experience as a researcher ;-). Anyway, this seemed like a good time to introduce our work and try to get some feedback on it. We've put a copy of our paper at: http://www.cs.washington.edu/homes/savage/traceback.html If you have a moment, we'd definitely appreciate any comments you might have. We're also especially interested in getting feedback from the ISP operations community and from equipment vendors, so please feel free to forward this to anyone you think might be interested. Thanks! - Stefan <savage@cs.washington.edu>, coauthor david wetherall <djw@cs.washington.edu> (and anna and tom) speaking of non-panaceas, brett mentioned caida passive monitoring for security. lemme clarify, coralreef has some bits that can detect port-scanning and then auto-trigger full framed collection on specific filter http://www.caida.org/Tools/CoralReef/ but it's quite different animal from traceback eg., what rstone's centertrack trying to do http://www.nanog.org/mtg-9910/robert.html (not sure where that stands wrt deployment) or what ddrew's cisco-based DOStracker did for what's.now.cw.net brettw also said if we installed passive monitors on IX links between providers, we might be able to do some interesting security traces. reckon you[pl.]'d have to install a lot of them and some facility for correlating among them (and at least coral doesn't have any of that yet, nor any kind of auto-paging when something looks suspicious) again, nothing money & hardware & code & a NOC contact list can't heavily dent in a year or 2 if folks wanted it badly enough. and with other positive benefits to boot. (in case folks think the malice of undersocial teenagers is the biggest threat we face...)
On Mon, 14 Feb 2000, k claffy wrote:
new relevant paper worth checking out by stefan savage et al
This is definately a must read. The idea is to mark packets with path information so that after you have recieved enough packets from a given source you can determine all of the routers it passed through. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
new relevant paper worth checking out by stefan savage et al
This is definately a must read.
I'd concur.
The idea is to mark packets with path information so that after you have recieved enough packets from a given source you can determine all of the routers it passed through.
It's important to state the operational impact here, which the paper doesn't do very clearly in the abstract or the front matter, and I think that's suboptimal structuring -- marking the packets is done by placing localtional information in the ip_id field of the packet. Quoting from my response to the authors and my inquiry cisco about implementation feasability: a) I don't like it because I must be the sole person (ok, ok, blatant exaggeration) in the universe who likes to use the ip_id field of ip packets as a debugging key when looking at packet traces; ip_id is typically monotonically increasing and a great way to check duplicates, etc., etc. b) It marks packets and marking packets is Bad and reduces the cleanliness of the model. c) Nevertheless, it seems like this could be an incredibly valuable tool for doing tracebacks, and despite the recent focus of the community on distributed denial-of-service attacks, the ability to do this sort of traceback between multiple providers without involving provider personnel in each "AS island" is much-needed. d) I think that c) almost certainly outweighs b) and a) in terms of operational necessity. e) There exists an argument that states that even with distributed denial of service attacks the ability to trace individual ones remains quite valuable. I don't want to go into it here right now. I also suggest 2 minor modifications to the model: i) Triggering this behavior off of a bgp community (opt-in and opt-out variants. ii) Allowing last-hop routers to collect this information instead of merely allowing the targetted hosts to collect it. --jhawk
participants (3)
-
Forrest W. Christian -
John Hawkinson -
k claffy