< draft-ietf-repute-considerations-00.txt   draft-ietf-repute-considerations-01.txt >
REPUTE M. Kucherawy REPUTE M. Kucherawy
Internet-Draft November 8, 2012 Internet-Draft May 5, 2013
Intended status: Informational Intended status: Informational
Expires: May 12, 2013 Expires: November 6, 2013
Operational Considerations Regarding Reputation Services Operational Considerations Regarding Reputation Services
draft-ietf-repute-considerations-00 draft-ietf-repute-considerations-01
Abstract Abstract
The use of reputation systems is has become a common tool in many The use of reputation systems is has become a common tool in many
applications that seek to apply collected intelligence about traffic applications that seek to apply collected intelligence about traffic
sources. Often this is done because it is common or even expected sources. Often this is done because it is common or even expected
operator practice. It is therefore important to be aware of a number operator practice. It is therefore important to be aware of a number
of considerations for both operators and consumers of the data. This of considerations for both operators and consumers of the data. This
document includes a collection of the best advice available regarding document includes a collection of the best advice available regarding
providers and consumers of reputation data, based on experience to providers and consumers of reputation data, based on experience to
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 12, 2013. This Internet-Draft will expire on November 6, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Reputation Clients . . . . . . . . . . . . . . . . . . . . . . 4 4. Reputation Clients . . . . . . . . . . . . . . . . . . . . . . 4
5. Reputation Service Providers . . . . . . . . . . . . . . . . . 6 5. Reputation Service Providers . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Reputation services involve collecting feedback from the community Reputation services involve collecting feedback from the community
about sources of Internet traffic and aggregating that feedback into about sources of Internet traffic and aggregating that feedback into
a rating of some kind. Common examples include feedback about a rating of some kind. Common examples include feedback about
traffic associated with specific email addresses, URIs or parts of traffic associated with specific email addresses, URIs or parts of
URIs, IP addresses, etc. The specific collection, analysis, and URIs, IP addresses, etc. The specific collection, analysis, and
rating methods vary from one service to the next and one problem rating methods vary from one service to the next and one problem
domain to the next, but several operational concepts appear to be domain to the next, but several operational concepts appear to be
skipping to change at page 4, line 26 skipping to change at page 4, line 26
addresses, allowing users to rely on these to identify and give addresses, allowing users to rely on these to identify and give
preferential treatment to their traffic. Good actors have no need to preferential treatment to their traffic. Good actors have no need to
hop around to different addresses, and already work to keep their hop around to different addresses, and already work to keep their
traffic clean. traffic clean.
This notion has only been tried to date using manually edited This notion has only been tried to date using manually edited
whitelists, but has shown promising results on that scale. whitelists, but has shown promising results on that scale.
4. Reputation Clients 4. Reputation Clients
understand that you are granting a third party the ability to affect Operators that choose to make use of reputation services to influence
your incoming traffic, for better or worse content allowed to pass into or through their infrastructures need to
understand that they are granting a third party (the reputation
this is the point, of course, when everything works properly service provider, or RSP) the ability to affect incoming traffic, for
better or worse. Of course, this is the whole point of engaging an
RSP when everything is working properly, but a number of issues are
worthy of consideration before establishing such a relationship.
some cases have occurred where a reputation service provider (RSP) Some cases have occurred where an RSP made the unilateral decision to
shut down operation, and to encourage consumers to stop querying, it terminate its service. To encourage its clients to stop issuing
began reporting a maximal negative reputation about all subjects, queries, it began reporting a maximally negative reputation about all
causing rejection of all incoming traffic during the incident period subjects, causing rejection of all incoming traffic during the
incident period. Although one would hope such incidents to be rare,
automated means to detect such unfortunate returns (malicious or
otherwise) and take remedial should be considered.
reputation providers will be the subject of attacks when it's RSPs will be the subject of attacks once it is understood that sucess
understood that sucess doing so will allow malicious content to evade in doing so will allow malicious content to evade detection and
detection and filtering; clients need to be aware of possible filtering. Users of RSPs need to be aware of possible interruptions
interruptions in service availability or quality in service availability or quality.
understand that some actors will try to game the service, which means Similarly, some actors will try to "game" the service, which is to
that a reputation service is inherently fragile; for operational say that such actors will attempt to determine patterns of behavior
clients, this should prompt balanced and comparative, rather than that result in the reporting of favorable reputations, and in doing
unilateral, use of the service so, acquire artifically inflated reputations. One could reasonably
assume that a reputation service is inherently fragile. For
operational clients, this should prompt balanced and comparative,
rather than unilateral, use of the service.
try to learn the following things about your RSP, to understand your 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: exposure potential:
o their basis for listing or not listing particular subjects o the RSP's basis for listing or not listing particular subjects;
o if an RSP is paid by its listees, what are the rate and criteria
for rejection?
o how the provider collects data about subjects o if an RSP is paid by its listees, the rate and criteria for
rejection from being listed;
o how many data points are input to the reported reputation o how the RSP collects data about subjects;
o is reputation based on a reliable identifier? o how many data points are input to the reported reputation;
o how it etablishes reliability and authenticity of those data 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 o how data validity is maintained (e.g., on-going monitoring of the
reported data and sources) reported data and sources);
o how actively data validity is tracked (e.g., how changes are o how actively data validity is tracked (e.g., how changes are
detected) detected);
o how disputed reputations are handled o how disputed reputations are handled;
o how data expire o how often input data expire;
o is older information more or less influential than newer? o whether older information more or less influential than newer;
o is the reported reputation a scalar, a Boolean value, a collection o whether the reported reputation a scalar, a Boolean value, a
of values, or something else? collection of values, or something else;
o when transitioning among RSPs, determine the differences between o when transitioning among RSPs, the differences between them among
them among these above points; that is, does a particular score these above points; that is, whether a particular score from one
from one mean the same thing from the other? means the same thing from another.
ensure the capability of local overrides for cases where the client An operator using an RSP would be wise to ensure it has the
expects to disagree with the reported reputation capability to effect local overrides for cases where the client
expects to disagree with the reported reputation.
be able limit the impact of a negative reputation on content An operator should be able limit the impact of a negative reputation
acceptance; for example, rather than rejecting content outright when on content acceptance. For example, rather than rejecting content
a negative reputation is returned, simply subject it to additional outright when a negative reputation is returned, simply subject it to
local analyis additional (i.e., more thorough) local analyis before permitting the
traffic to pass.
have a sensible default to apply when the RSP is not available 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.
consider tailoring operation to prefer or emphasize content whose Recent proposals have focused on tailoring operation to prefer or
sources have positive reputations; recall that negative reputations emphasize content whose sources have positive reputations. As stated
are easy to shed, and the universe of things that will earn and above, negative reputations are easy to shed, and the universe of
maintain positive reputations is relatively small 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.
consider querying and cross-referencing multiple RSPs; this helps to One choice is to query and cross-referencing multiple RSPs. This can
detect which are reliable, and offsets the effect of anomalous help to detect which ones under comparison are reliable, and offsets
replies the effect of anomalous replies.
5. Reputation Service Providers 5. Reputation Service Providers
make the answers to the questions in Section 4 available on demand to Operators intending to provide a reptuation service need to consider
consumers 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
to answer as may of the questions identified in Section 4 as
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.
base reputations on accurate identifiers, i.e., something difficult Obviously, in computing reputations via traffic analysis, some
to forge 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.
it is important to have a transparent remediation process for Reptuations should be based on accurate identifiers, i.e., some
disputes of computed reputations property of the content under analysis that is difficult to falsify.
For example, in the realm of email, the address found in the From:
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.
provide the ability to request details in the returned result about The biggest frustration with most RSPs to date has been the absence
how the result was reached, allowing the client to decide if the of a visible, accessible, and transparent process for remediating the
result should be applied, such as: errant addition of an identifier to a negative reputation list. An
RSP in widespread use is perceived to have enormous power when its
results are used to reject traffic outright; when a "bad" entry is
added referencing a good actor, it can have destructive effects, so
an effective mechanism to fix such problems needs to exist.
o the result itself To accommodate clients with varying sensitivities, it is advisable
for the query mechanism used to access the RSP to provide the ability
to request details in the returned result about how the result was
reached, allowing the client to decide if the result should be
applied. For example, it shoudl be possible for the reply to
contain:
o the number of data points used to compute the result o the result itself;
o the age range of the data o the number of data points used to compute the result;
o source diversity of the input data o the age range of the data;
o currency of the result (i.e., when it was computed) o source diversity of the input data;
o basis of the result (i.e., which identifier was used) o currency of the result (i.e., when it was computed);
harden systems and algorithms as much as practicable against gaming o basis of the result (i.e., which identifier was used).
or data poisoning; larger source diversities are harder to overcome
with poisoned input, but are expensive to build
systems based on positive reputations are promising since positive The systems and algorithms used by the RSP to compute the reported
reputations, if made difficult to earm put a large cost on bad actors reputation will need to be hardened as much as practicable against
gaming or other forms of data poisoning. Larger source diversities
are harder to overcome with poisoned input, but are expensive to
build in terms of both infrastructure and time.
Systems focused on assigning positive reputations rather than negtive
ones are promising since positive reputations, if made difficult to
earn, put a large cost on bad actors, which may be enough to dissuade
them entirely.
6. Security Considerations 6. Security Considerations
Several points are raised above that can be described as threats to Several points are raised above that can be described as threats to
the delivery of valid user data. This document highlights and the delivery of valid user data. This document highlights and
discusses those issues, but introduces no new security issues. discusses those matters, but introduces no new security issues.
7. IANA Considerations 7. IANA Considerations
This memo contains no actions for IANA. This memo contains no actions for IANA.
[RFC Editor: Please remove this section prior to publication.] [RFC Editor: Please remove this section prior to publication.]
8. Informative References 8. Informative References
[DNS] Mockapetris, P., "Domain Names -- Concepts and Facilities", [DNS] Mockapetris, P., "Domain Names -- Concepts and Facilities",
skipping to change at page 7, line 19 skipping to change at page 8, line 21
[DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, [DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
February 2010. February 2010.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author wishes to acknowledge the following for their review and The author wishes to acknowledge the following for their review and
constructive criticism of this proposal: (names) constructive criticism of this proposal: Chris Barton, Vincent
Schonau
Author's Address Author's Address
Murray S. Kucherawy Murray S. Kucherawy
EMail: superuser@gmail.com EMail: superuser@gmail.com
 End of changes. 42 change blocks. 
79 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/