[domainrep] Reputation algorithms

[Tyson Macaulay <[e-mail]>]

HI again,

In a soon to be released INFORMATIONAL RFC -
draft-macaulay-6man-reputation-intelligence-00 we propose criteria for
reputation intelligence algorithms.  These appear to partially overlap
with your complimentary conclusions in draft-ietf-repute-media-type-02 -
Section 3.1, but we have some supplementary criteria.

(It will be a few more days before I get the INFORMATIONAL RFC on line due
to a family vacation.  Email me if you want a pre-00 version right away.)

Also - it is entirely possibly your intention that many of these
criteria are implicit and not required in the replies to reputation
queries.(?)  In our current model, all criteria except the reputation
score 
itself is held within the intelligence algorithm rather than communicated
in the reputation query-response.

Below I have tried to map your reputation criterium against ours - or
indicate where there is no mapping:

REPUTON "Rater" =   Implicit in selection of query destination in our
model.

REPUTON "Application" =  Implicit intended app is "packet staining" as per
draft-macaulay-6man-packet-stain-00

REPUTON "Assertion" = no mapping

REPUTON "Rated" = indicated by the source address of the packet

REPUTON "Rating" = Reputation score to be encoded in header extension

REPUTON "Confidence" = no mapping at this time.

REPUTON "Authenticity" = no mapping.  This is a management control
(business-level decision) in our model.

REPUTON "Sample size" = Function 8 (approximately)

REPUTON "Updated" = Function 2, 6, 7 (approximately)

Algorithmic functions as per
draft-macaulay-6man-reputation-intelligence-00

Function 1:  to account for large Internet portals with many, independent
URLs with good reputations, but also some proportion of dangerous (bad
reputation) URLs sharing the same IP address = no REPUTON mapping?

Function 2:  to account for the distance in time between the last observed
suspicious or illicit behaviour and the present Function 3:  to account
for the reputations of both adjacent IP addresses or domains = REPUTON
"Updated" (approximately?)


Function 4: to account for the original, per-processed source of the
intelligence (open source, closed source, domain of control, uncontrolled
domain) = no REPUTON mapping

Function 5:  to account for the velocity of suspicious or illicit
behaviour (IE. high Spam rate) = no REPUTON mapping

Function 6:  to account for the duration of suspicious or illicit
behaviour (IE. sustained spam at low velocity) = REPUTON "Updated"
(approximately?)

Function 7:  to account for lifetime of domain to source IP associations
(IE. newly minted domain names or previously unobserved/ un-assigned
addresses = REPUTON "Updated" (approximately)

Function 8:  to account for the proportion of traffic from this source
which is benign versus demonstrably illicit = REPUTON "Sample size"
(approximately?)

Function 9:  to account of the nature of the suspicious or illicit
behaviour (automated port scanning versus malware-drop) = no REPUTON
mapping

What are your impressions of this criteria from our draft? Do you feel
they are valid in the context of intelligence algorithms?  Is there any
particular reason they are not explicit in your "Reputon Keys" in Section
3.1?

Thanks,

Tyson 

PS - again - we (my co-authors) think your work here is great, and the
direction we need to go in order to establish networks with the necessary
assurance in the future.

--
Tyson Macaulay, BA CISSP CISA
VP ­ Technology
2Keys Security Solutions
Phone: [phone]
email: [e-mail]