[145028] in North American Network Operators' Group
Re: "general badness" AS-based reputation system
daemon@ATHENA.MIT.EDU (Manish Karir)
Mon Sep 26 01:12:04 2011
From: Manish Karir <mkarir@merit.edu>
In-Reply-To: <A0C871B5-DAE5-433B-9331-6907F3D13053@eyeconomics.com>
Date: Mon, 26 Sep 2011 01:11:50 -0400
To: Tom Vest <tvest@eyeconomics.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sep 25, 2011, at 11:31 PM, Tom Vest wrote:
>=20
> On Sep 25, 2011, at 9:23 PM, Manish Karir wrote:
>=20
>> On Sep 25, 2011, at 6:31 PM, nanog-request@nanog.org wrote:
>>=20
>>> Message: 9
>>> Date: Sun, 25 Sep 2011 18:37:17 +0300
>>> From: Gadi Evron <ge@linuxbox.org>
>>> To: nanog@nanog.org
>>> Subject: "general badness" AS-based reputation system
>>> Message-ID: <4E7F4AAD.8020400@linuxbox.org>
>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>>>=20
>>> Having run one of these in the past, when take-downs of C&Cs was =
still=20
>>> semi-useful, my ethos on this is problematic, however, I am as of =
yet=20
>>> undecided as to this one. An AS-based reputation system for all =
sorts of=20
>>> badness:
>>>=20
>>> http://bgpranking.circl.lu/
>>>=20
>>> In my opinion, third-party security based AS-reputation systems will=20=
>>> eventually become de-facto border filtering systems for ISPs, but =
that=20
>>> day is still not here, as that is still socially unacceptable in our=20=
>>> circles, and will remain so until it becomes _necessary_.
>>>=20
>>> Regardless of my musings of Operators World cultural future, this=20
>>> systems seems rather interesting, and no doubt you'd want to take a =
look=20
>>> at your listing.
>>>=20
>>> Gadi.
>>=20
>> We tried to outline some of the challenges of building such a system =
in our NANOG52 presentation:
>>=20
>> =
http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-na=
nog.pdf
>>=20
>> In particular see slide 4. where we tried to lay down what we think =
the requirements are for a socially acceptable
>> reputation system. =20
>>=20
>> With a bit of luck we might be able to announce the release of our =
system before the next NANOG mtg, but in=20
>> my opinion collating host reputation reports is just a small and the =
easiest part of the effort. The key is in=20
>> solving the challenges of allowing (and incentivizing) participation =
and being robust to false information
>> injection.
>>=20
>> Comments are welcome.
>>=20
>> Thanks.
>> -manish
>=20
> Hi Manish,=20
>=20
> Looks like very interesting work.
>=20
> Does the system that you'll be announcing provide some means of coming =
to terms with challenges like the following?
>=20
> 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?
>=20
> 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")?=20
>=20
> 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.=20
>=20
> 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."
>=20
> Look forward to hearing more!
>=20
> Regards,=20
>=20
> TV
>=20
>=20
>=20
>=20
>=20
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=20
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=20
does'nt allow for different parts of an organization which might run =
their networks with different policies. =20
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=20
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
