[domainrep] Review of: draft-ietf-repute-considerations-01

[Dave Crocker <[e-mail]>]

{ This review is provided as part of document shepherding. /d }



Review of:    Operational Considerations Regarding Reputation Services
ID:           draft-ietf-repute-considerations-01
Reviewed by:  D. Crocker
Review Date:  19 May 2013



Summary:

This document offers commentary on the operation of reputation related 
services.  It contains advice both for providers and for consumers of 
such information.  The document is intentionally basic, but seems 
pragmatic.  Guidance offered is primarily of the "consider this" or 
"watch for that" style, rather than attempting operational procedures. 
However it does suggest a kind of detailed questionnaire for consumers 
to use when choosing a provider.

The document is usable in its current form.  A few minor suggestions are 
offered in the Detailed Comments.



Detailed Comments:


> 2.  Background
...
>
>    However, regardless of the identifier used as the identifier for a
>    reputation, bad actors can evade detection or the effects of their

they can evade the effects?  I suspect the sentence is meant to 
differently.  Possibly:

   bad actors can evade detection or its consequences by changing...


>    observed behavior by changing identifiers (e.g., move to a new IP
>    address, register a new domain name, use a sub-domain).  This makes
>    the problem space effectively boundless, especially as IPv6 rolls
>
>
>
> Kucherawy               Expires November 6, 2013                [Page 3]
> 
> Internet-Draft            Reputation Operations                 May 2013
>
>
>    out.

out, with its vastly larger address space.


>
> 3.  Evolution
...
>
>    Moreover, good actors tend to be represented by stable names and
>    addresses, allowing users to rely on these to identify and give
>    preferential treatment to their traffic.  Good actors have no need to
>    hop around to different addresses, and already work to keep their
>    traffic clean.

In addition, good actors are willing and able to collaborate in the 
assessment process, such as by supplying validated identifiers, 
associated with their traffic.

>
>    This notion has only been tried to date using manually edited

Which notion?


>    whitelists, but has shown promising results on that scale.
>
> 4.  Reputation Clients
...
>    It is suggested that, when engaging an RSP, an operator should try to
>    learn the following things about the RSP in order to understand the
>    exposure potential:
>
>    o  the RSP's basis for listing or not listing particular subjects;
>
>    o  if an RSP is paid by its listees, the rate and criteria for
>       rejection from being listed;
>
>    o  how the RSP collects data about subjects;
>
>    o  how many data points are input to the reported reputation;
>
>    o  whether reputation is based on a reliable identifier;
>
>    o  how the RSP establishes reliability and authenticity of those
>       data;
>
>    o  how data validity is maintained (e.g., on-going monitoring of the

how continuing data validity is maintained


>       reported data and sources);
>
>    o  how actively data validity is tracked (e.g., how changes are
>       detected);
>
>    o  how disputed reputations are handled;
>
>    o  how often input data expire;
>
>    o  whether older information more or less influential than newer;

is more or


>
>    o  whether the reported reputation a scalar, a Boolean value, a
>       collection of values, or something else;
>
>    o  when transitioning among RSPs, the differences between them among
>       these above points; that is, whether a particular score from one
>       means the same thing from another.
>
>    An operator using an RSP would be wise to ensure it has the
>    capability to effect local overrides for cases where the client
>    expects to disagree with the reported reputation.
>
>    An operator should be able limit the impact of a negative reputation
>    on content acceptance.  For example, rather than rejecting content
>    outright when a negative reputation is returned, simply subject it to
>    additional (i.e., more thorough) local analyis before permitting the
>
>
>
> Kucherawy               Expires November 6, 2013                [Page 5]
> 
> Internet-Draft            Reputation Operations                 May 2013
>
>
>    traffic to pass.

Hmmm.  This suggests a "layers of assessment" model, parallel to the 
common idea of layering security protection.  In other words, don't put 
all your reputation decision-making into a single basket, especially 
when a third party is holding the basket.


>    A sensible default should apply when the RSP is not available.  This
>    may also be a query to a different RSP known to be less robust than
>    the primary one.

may -> can


>
>    Recent proposals have focused on tailoring operation to prefer or
>    emphasize content whose sources have positive reputations.  As stated
>    above, negative reputations are easy to shed, and the universe of

and -> while


>    things that will earn and maintain positive reputations is relatively
>    small.  Designing a filtering system that observes these notions is
>    expected to be more lightweight to operate and harder to game.
>
>    One choice is to query and cross-referencing multiple RSPs.  This can
>    help to detect which ones under comparison are reliable, and offsets
>    the effect of anomalous replies.
>
> 5.  Reputation Service Providers
>
>    Operators intending to provide a reptuation service need to consider
>    that there are many flavors of clients.  There will be clients that
>    are prepared to make use of a reputation service blindly, while
>    others will be interested in understanding more fully the nature of
>    the service being provided.  An operator of an RSP should be prepared

I typically compare these alternative to "yes/no check approval" versus 
"getting a full credit report".


>    to answer as may of the questions identified in Section 4 as

may -> many


>    possible, not only because wise clients will ask, but also because
>    they reflect issues that have arisen over the years, and exploration
>    of the points they raise will result in a more robust reputation
>    service.
>
>    Obviously, in computing reputations via traffic analysis, some
>    private algorithms may come into play.  For some RSPs, such "secret
>    sauce" comprises their competitive advantage over others in the same
>    space.  This document is not suggesting that all private algorithms
>    need to be exposed for a reputation service to be acceptable.
>    Instead, it is anticipated that enough of the above details need to
>    be available to ensure consumers (and in some cases, industry or the
>    general public) that the RSP can be trusted to influence key local
>    policy decisions.
>
>    Reptuations should be based on accurate identifiers, i.e., some
>    property of the content under analysis that is difficult to falsify.
>    For example, in the realm of email, the address found in the From:

rfc5322.From -- or -- From: header field

{ people occasional see From and thing Mail From. /d }


>    field of a message is typically not verifiable, while the domain name
>    found in a validated domain-level signature is.  In this case,
>    constructing a reputation system based on the domain name is more
>    useful than one based on the From: field.


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net