I would probably limit this to simply identifying rogue prefixes [such as those prefixes - and there are some - owned entirely by criminal spammers, botnet C&Cs etc]
[let us not get into a discussion on listing criteria or what constitutes criminal spam just now, there's a whole lot of such discussion and even a decent RFC draft] http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-07 On Mon, Sep 26, 2011 at 10:41 AM, Manish Karir <mka...@merit.edu> wrote: > > On Sep 25, 2011, at 11:31 PM, Tom Vest wrote: > > > > > On Sep 25, 2011, at 9:23 PM, Manish Karir wrote: > > > >> On Sep 25, 2011, at 6:31 PM, nanog-requ...@nanog.org wrote: > >> > >>> Message: 9 > >>> Date: Sun, 25 Sep 2011 18:37:17 +0300 > >>> From: Gadi Evron <g...@linuxbox.org> > >>> To: nanog@nanog.org > >>> Subject: "general badness" AS-based reputation system > >>> Message-ID: <4e7f4aad.8020...@linuxbox.org> > >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>> > >>> Having run one of these in the past, when take-downs of C&Cs was still > >>> semi-useful, my ethos on this is problematic, however, I am as of yet > >>> undecided as to this one. An AS-based reputation system for all sorts > of > >>> badness: > >>> > >>> http://bgpranking.circl.lu/ > >>> > >>> In my opinion, third-party security based AS-reputation systems will > >>> eventually become de-facto border filtering systems for ISPs, but that > >>> day is still not here, as that is still socially unacceptable in our > >>> circles, and will remain so until it becomes _necessary_. > >>> > >>> Regardless of my musings of Operators World cultural future, this > >>> systems seems rather interesting, and no doubt you'd want to take a > look > >>> at your listing. > >>> > >>> Gadi. > >> > >> We tried to outline some of the challenges of building such a system in > our NANOG52 presentation: > >> > >> > http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf > >> > >> In particular see slide 4. where we tried to lay down what we think the > requirements are for a socially acceptable > >> reputation system. > >> > >> With a bit of luck we might be able to announce the release of our > system before the next NANOG mtg, but in > >> my opinion collating host reputation reports is just a small and the > easiest part of the effort. The key is in > >> solving the challenges of allowing (and incentivizing) participation and > being robust to false information > >> injection. > >> > >> Comments are welcome. > >> > >> Thanks. > >> -manish > > > > Hi Manish, > > > > Looks like very interesting work. > > > > Does the system that you'll be announcing provide some means of coming to > terms with challenges like the following? > > > > 1. Many large operators administer multiple ASNs, but some of the > resulting AS sibling relationships may not be identifiable as such based on > public-facing whois records, or interconnection relationships, or any other > public data sources. Does your system incorporate some means of attributing > reputation-related information at the (multi-AS) institutional level -- even > when the contours of such institutions are not self-evident? > > > > 2. Some members of the ARIN community have recently floated a policy > proposal which if approved would make ASNs transferable, and some supporters > of that proposal have argued that RIR involvement in such transfers should > be strictly limited to the passive recording of whatever information is > voluntarily disclosed by the transacting parties, if and when a disclosure > is made. Does your system ascribe reputation "strictly" to specific ASNs, > such that declared changes in an ASN's "ownership"/control would not affect > that ASNs accumulated reputation record to-date? Alternately, if declared > changes to an ASN's ownership would affect (e.g., restart) an ASN's > reputation history, will your system incorporate some mechanism for > assessing the material/operational "substance" of ASN re-registration events > (e.g., to filter for possible "re-registrations of convenience")? > > > > I like to ask these sort of questions (for any/all proposed systems like > this) because it seems to me that any system that associates increasing > value with a cumulative record of consistent "approved" behavior over time > must take extra care not to provide *asymmetrical* opportunities (i.e., to > some but not all participants) to isolate and sanitize their own > "disapproved" behavior, thereby leaving their longstanding (favorable) > reputations intact. > > > > Note that this problem is *not* reducible to the idea that a reputation > system must be absolutely infallible. Obviously it is not reasonable to > demand something that is impossible to deliver. However, it is altogether > reasonable to demand that any system that is intentionally designed to > produce a new, endogenously-driven reputation-based hierarchy of operational > entities does something more than just recreate and reinforce pre-existing > hierarchies that are completely orthogonal to "reputation." > > > > Look forward to hearing more! > > > > Regards, > > > > TV > > > > > > > > > > > > Hi Tom, > > At what granularity reputation is useful is an excellent question. > Obviously we already have lots of single data source based host reputation > sources. > Other possible aggregations are prefixes, ASNs, and as you suggest > organizations (which might be multi-ASN). Another extreme possible > aggregation is country. > > In my opinion BGP prefix is the right level of aggregation up to be > actually useful rather than narrow host reputation lists. You might expect > hosts in a > prefix to be under the same security policy regime and hence have similar > likelihood of future malicious behavior so this approach would be more > useful than host reputation which is entirely reactive and ASN reputation > which > does'nt allow for different parts of an organization which might run their > networks with different policies. > > In our system an ASN's reputation at any given time is based on aggregating > up the reputation of all the prefixes originated by that ASN. Therefore it > does > not really have a reputation that exists independently of its component > prefixes. If an ASN were to be transferred we would simply recompute the > current reputation to be based on the new set of prefixes it is > originating. > > For prefix reputation you would want to track it on a historical basis with > the assumption that it is quite unlikely that a prefixes reputation will > undergo a sudden change and therefore tracking historical data would be > useful. We do not do this right now, but this is not a solved problem yet > ;) > > -manish > > > > > > > > -- Suresh Ramasubramanian (ops.li...@gmail.com)