Subject: [domainrep] Test application reg under repute-media-type

From: Tyson Macaulay <[email-masked]>
Date: Tue, 22 May 2012 07:20:38 -0400

HI,

I took a look at repute-media-type-02 and the proposed IANA application
registration in order to see how it might look like if the application was
"packet staining", as tentatively defined in
draft-macaulay-6man-packet-staining-00.

"5.2. Reputation Applications Registry

IANA is requested to create the "Reputation Applications" registry.
This registry will contain names of applications used with the
application/reputon+json media type (and other media types that carry
reputons), as defined by this document.
New registrations or updates MUST be published in accordance with the
"Specification Required" guidelines as described in
[IANA-CONSIDERATIONS]."

SAMPLE REGISTRATION FOR STAITING

New registrations and updates MUST contain the following information:
1. Name: packet staining
2. Purpose: For encoding the reputation of a source address within IPv6
packet header extensions
3. Documentation: Draft-macaulay-6man-packet-staining-00
4. Status: current 
5. A description of the subject of a query: ip-address, address-range
(i.e. /64) domain name  <<I suspect that these would each have to be
distance IANA registrations?>>
6. An optional table of query parameters that are specific to this
application; each table entry must include:

<< I will make a separate post on this topic related to reputation
algorithms>>

ASSERTIONS: 
Name: indicator of malice or compromise

Description: the degree to which the IP, IP-range, domain is generating
traffic indicative of malicious influence or compromised. Example: 0.0 =
no evidence of malice or compromise / benign IP;  1.0 = complete assurance
of contemporary malice or compromise-related activity

Scale: Not sure how this differs from "Description" above.  Also - see
other "algorithm" thread in this list.

Extension Key Name: (not sure about this either.  Perhaps an indicator of
with the reputation applies to the ip, /64 or domain name?)

Description: Allow a reputation score to be provided based on source IP,
adjacent IPs or non-adjacent IPs under the same ASN (mutli-homed
environments suffering compromise or  acting in a malicious manner)

Syntax:   Suggestions?

Note: This is great work.  I believe it is also very complimentary to what
is being proposed in 6man, too.

Tyson

--
Tyson Macaulay, BA CISSP CISA
VP  Technology
2Keys Security Solutions
Phone: +1 613 292 9132
email: [email-masked]

---

From: Tyson Macaulay <[email-masked]>
Date: Tue, 22 May 2012 07:24:52 -0400

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 25 May 2012 06:50:55 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tyson Macaulay
> Sent: Tuesday, May 22, 2012 4:21 AM
> To: [email-masked]
> Subject: [domainrep] Test application reg under repute-media-type
> 

I would probably call it "packet-staining" or even something more general like "tcp-sources".

> 3. Documentation: draft-macaulay-6man-packet-staining-00

Is that where you plan to define any query or response set extensions?  If so, the registration should just go in that document directly along with whatever else is in there.

> (i.e. /64), domain name  <<I suspect that these would each have to be

Saying the subject of the query is either an IP address or a CIDR expression is probably fine.  In the reply, you don't have to report on the same thing.  For example, you might ask about an IP address and get back a CIDR block if you've aggregated reputation in that way.  (See what ARIN's RESTful WHOIS query does, for example.)

Are you planning to tie "stains" to domain names?  How would that work?

> Name: indicator of malice or compromise

You would list assertion names here like "MALICIOUS" or "COMPROMISED", and explain for each what 0 and 1 mean in Description.

> other "algorithm" thread in this list.

The scale is just an indication if one travels from 0 to 1 linearly, exponentially, logarithmically, etc.

> Extension Key Name: (not sure about this either.  Perhaps an indicator
> of with the reputation applies to the ip, /64 or domain name?)

You don't have to have extensions to the query or reply if you don't need them.  You could reply with the specific IP that was the subject of the query, and then include as extensions the CIDR block you think contains it and the domain name(s) you think are associated with them.  This gives the client a clearer picture of your view of the subject.

> Note: This is great work.  I believe it is also very complimentary to
> what is being proposed in 6man, too.

Happy to hear it's useful!

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 25 May 2012 19:31:24 +0000

> Sent: Tuesday, May 22, 2012 4:25 AM
> To: [email-masked]
> Subject: [domainrep] Reputation algorithms
> 
> HI again,
> 
> with your complimentary conclusions in draft-ietf-repute-media-type-02
> - Section 3.1, but we have some supplementary criteria.
>
> [...]
> 
> REPUTON "Rater" =   Implicit in selection of query destination in our model.

It's re-stated in the reply in case the service (host) you used in the query URI is an alias for something else, and you want to know who ultimately answered you.

> draft-macaulay-6man-packet-stain-00

Yep; you'll need to re-state it in our model in case the reputation service operates in many reputation application spaces, to be sure you got a meaningful answer.

> REPUTON "Assertion" = no mapping

For repute, the absence of this means "IS-GOOD" (Section 3.1 of our media-type document).

> (business-level decision) in our model.

These are optional anyway.

> Function 1:  to account for large Internet portals with many,
> independent URLs with good reputations, but also some proportion of dangerous (bad

If you have a source IP address producing several streams with distinct behaviours, but are unable to distinguish them, then the best you can do is deliver a reputon about the source IP address or the/a CIDR block containing it.

> 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?)

Roughly.  "Updated" is meant to indicate "this is when this rating was calculated" so you can see how stale it is.  If that's not what you need, you can declare an extension.

> domain) = no REPUTON mapping

I'm not sure what this is.  You might be able to relay this via the "RATER" parameter in the reply, or if that overloading is distasteful, you can simply declare an extension in your response set that indicates what the intelligence source is.

> behaviour (IE. high Spam rate) = no REPUTON mapping

This would be an extension, maybe "RATE-OF-CHANGE" or "VELOCITY" or something.

> behaviour (IE. sustained spam at low velocity) = REPUTON "Updated"

If your rating scale is such that there's a threshold of interest (0.5, let's say), then you could have an extension to indicate how long the subject has been above that threshold.

> 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)

Extension, although now your subject is a complex one (i.e., something like IP:domain).

> which is benign versus demonstrably illicit = REPUTON "Sample size"

I would think that factors into the rating itself.

> behaviour (automated port scanning versus malware-drop) = no REPUTON

This would be a set of assertions you define in your response set other than the default "IS-GOOD".

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 25 May 2012 19:39:18 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Friday, May 25, 2012 12:31 PM
> To: [email-masked]
> Subject: Re: [domainrep] Reputation algorithms
> 
> It's re-stated in the reply in case the service (host) you used in the
> query URI is an alias for something else, and you want to know who
> ultimately answered you.
>
> [...]

Tyson,

You might want to try drafting up an individual submission that defines your repute application. This would be a good test to see if your work is a fit for this, and also a good test as to whether we've done a good job with our existing documents.

You could use the email-identifiers document as a template.

-MSK