[103774] in North American Network Operators' Group
Re: the O(N^2) problem
daemon@ATHENA.MIT.EDU (Edward B. DREGER)
Mon Apr 14 01:59:35 2008
Date: Mon, 14 Apr 2008 05:57:22 +0000 (GMT)
From: "Edward B. DREGER" <eddy+public+spam@noc.everquick.net>
To: nanog@merit.edu
cc: Owen DeLong <owen@delong.com>,
Suresh Ramasubramanian <ops.lists@gmail.com>
In-Reply-To: <bb0e440a0804132227x1680d8a6l47db6c25d6d434f0@mail.gmail.com>
Errors-To: owner-nanog@merit.edu
Stardate Mon, 14 Apr 2008, Suresh Ramasubramanian's log:
SR> From: Suresh Ramasubramanian
SR> Looks like what various people in the industry call a "reputation
SR> system"
I started responding; Suresh's reply came as I was doing so, and put it
very succinctly. Reputation system, but inter-"network". Perhaps an
example would work better than my vague descriptions. :-)
Let's say I receive email from:
From: <owen@...>
Received: from ... (owen.delong.sj.ca.us [192.159.10.2])
Should I trust the message? I don't "know" you. However, I _do_ know
From: <owen@...>
Received: from ... (trapdoor.merit.edu [198.108.1.26])
and trapdoor.merit.edu vouches for you. Elaborating, using "trust
paths", *not* SMTP or routing paths:
<owen@...> # distrust metric: initially 0
owen.delong.sj.ca.us # distrust metric: still 0
trapdoor.merit.edu # dm: 1 (it mostly believes your MX)
mail.everquick.net # dm: 2 (more or less trust NANOG)
versus
<owen@...> # dm: 0
malicious.host.domain.tld # dm: 0 (trying to impersonate)
trapdoor.merit.edu # dm: 10 (doesn't yet trust above host)
mail.everquick.net # dm: 16 (after whatever local mods)
or
<somenewaddress@...> # dm: 0
owen.delong.sj.ca.us # dm: 0 (your MX can vouch)
trapdoor.merit.edu # dm: 1 (more or less believes your MX)
mail.everquick.net # dm: 2 (more or less trust NANOG)
IOW, I receive email from an unrecognized address from your MX. Do I
trust it? I mostly trust trapdoor.merit.edu, which mostly trusts your
MX, which totally trusts <somenewaddress@...>. Therefore, I conclude
that I largely trust the message.
For such a system to scale, it would need to avoid OSPF-style
convergence. Similarly, I would not want to query, for the sake of
example, 15k different "trust peers" each time I needed to validate a
new <host,address> tuple. (Hence the interdomain routing and d-v calc
references.)
Therefore, one would find the locally-optimal solution at each "trust
hop", a la interdomain routing.
Perhaps PGP/GPG would be the best analogy. (When I said "PKI", I should
have stated CA-based PKI; my original wording was excessively broad, and
should have explicitly excluded PGP.)
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
________________________________________________________________________
DO NOT send mail to the following addresses:
davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
