< draft-ietf-repute-considerations-01.txt   draft-ietf-repute-considerations-02.txt >
REPUTE M. Kucherawy REPUTE M. Kucherawy
Internet-Draft May 5, 2013 Internet-Draft May 20, 2013
Intended status: Informational Intended status: Informational
Expires: November 6, 2013 Expires: November 21, 2013
Operational Considerations Regarding Reputation Services Operational Considerations Regarding Reputation Services
draft-ietf-repute-considerations-01 draft-ietf-repute-considerations-02
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 November 6, 2013. This Internet-Draft will expire on November 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 8 8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 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
skipping to change at page 3, line 49 skipping to change at page 3, line 49
A specific example of a reputation service in common use in the email A specific example of a reputation service in common use in the email
space is the DNS blacklist [DNSBL]. This is a method of querying a space is the DNS blacklist [DNSBL]. This is a method of querying a
database as to whether a source of incoming [SMTP] email traffic database as to whether a source of incoming [SMTP] email traffic
should be allowed to relay email, based on previous observations and should be allowed to relay email, based on previous observations and
feedback. The method uses the IP address of the source as the basis feedback. The method uses the IP address of the source as the basis
for a query to the database using the Domain Name System [DNS] as the for a query to the database using the Domain Name System [DNS] as the
interface. [DNSBL] includes several points in its Security interface. [DNSBL] includes several points in its Security
Considerations document that are repeated and further developed here. Considerations document that are repeated and further developed here.
However, regardless of the identifier used as the identifier for a However, regardless of the identifier used as the identifier for a
reputation, bad actors can evade detection or the effects of their reputation, bad actors can evade detection or its consequences by
observed behavior by changing identifiers (e.g., move to a new IP changing identifiers (e.g., move to a new IP address, register a new
address, register a new domain name, use a sub-domain). This makes domain name, use a sub-domain). This makes the problem space
the problem space effectively boundless, especially as IPv6 rolls effectively boundless, especially as IPv6 rolls out, with its vastly
out. larger address space.
3. Evolution 3. Evolution
More modern thinking is evolving toward the identification of good More modern thinking is evolving toward the identification of good
actors rather than bad actors, and giving them preferential actors rather than bad actors, and giving them preferential
treatment. This drastically reduces the problem space: There are treatment. This drastically reduces the problem space: There are
vastly more IP addresses and email addresses used by bad actors to vastly more IP addresses and email addresses used by bad actors to
generate problematic traffic than are used by good actors to generate generate problematic traffic than are used by good actors to generate
desirable traffic. desirable traffic.
Moreover, good actors tend to be represented by stable names and Moreover, good actors tend to be represented by stable names and
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. In addition, good actors are willing and able to
collaborate in the assessment process, such as by supplying validated
identifiers that are associated with their traffic.
This notion has only been tried to date using manually edited This new approach of focusing on identification of good actors has
whitelists, but has shown promising results on that scale. only been tried to date using manually edited whitelists, but has
shown promising results on that scale.
4. Reputation Clients 4. Reputation Clients
Operators that choose to make use of reputation services to influence Operators that choose to make use of reputation services to influence
content allowed to pass into or through their infrastructures need to content allowed to pass into or through their infrastructures need to
understand that they are granting a third party (the reputation understand that they are granting a third party (the reputation
service provider, or RSP) the ability to affect incoming traffic, for service provider, or RSP) the ability to affect incoming traffic, for
better or worse. Of course, this is the whole point of engaging an 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 RSP when everything is working properly, but a number of issues are
worthy of consideration before establishing such a relationship. worthy of consideration before establishing such a relationship.
skipping to change at page 5, line 25 skipping to change at page 5, line 28
o how the RSP collects data about subjects; o how the RSP collects data about subjects;
o how many data points are input to the reported reputation; o how many data points are input to the reported reputation;
o whether reputation is based on a reliable identifier; o whether reputation is based on a reliable identifier;
o how the RSP establishes reliability and authenticity of those o how the RSP establishes reliability and authenticity of those
data; data;
o how data validity is maintained (e.g., on-going monitoring of the o how continuing data validity is maintained (e.g., on-going
reported data and sources); monitoring of the 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 often input data expire; o how often input data expire;
o whether older information more or less influential than newer; o whether older information is more or less influential than newer;
o whether the reported reputation a scalar, a Boolean value, a o whether the reported reputation a scalar, a Boolean value, a
collection of values, or something else; collection of values, or something else;
o when transitioning among RSPs, the differences between them among o when transitioning among RSPs, the differences between them among
these above points; that is, whether a particular score from one these above points; that is, whether a particular score from one
means the same thing from another. means the same thing from another.
An operator using an RSP would be wise to ensure it has the An operator using an RSP would be wise to ensure it has the
capability to effect local overrides for cases where the client capability to effect local overrides for cases where the client
expects to disagree with the reported reputation. expects to disagree with the reported reputation.
An operator should be able limit the impact of a negative reputation An operator should be able limit the impact of a negative reputation
on content acceptance. For example, rather than rejecting content on content acceptance. For example, rather than rejecting content
outright when a negative reputation is returned, simply subject it to outright when a negative reputation is returned, simply subject it to
additional (i.e., more thorough) local analyis before permitting the additional (i.e., more thorough) local analysis before permitting the
traffic to pass. traffic to pass. In other words, the reputation may simply allow
certain layers of a multi-layered filtering system to be bypassed
when that reputation is favorable.
A sensible default should apply when the RSP is not available. This 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 can also be a query to a different RSP known to be less robust than
the primary one. the primary one.
Recent proposals have focused on tailoring operation to prefer or Recent proposals have focused on tailoring operation to prefer or
emphasize content whose sources have positive reputations. As stated emphasize content whose sources have positive reputations. As stated
above, negative reputations are easy to shed, and the universe of above, negative reputations are easy to shed, while the universe of
things that will earn and maintain positive reputations is relatively things that will earn and maintain positive reputations is relatively
small. Designing a filtering system that observes these notions is small. Designing a filtering system that observes these notions is
expected to be more lightweight to operate and harder to game. expected to be more lightweight to operate and harder to game.
One choice is to query and cross-referencing multiple RSPs. This can One choice is to query and cross-referencing multiple RSPs. This can
help to detect which ones under comparison are reliable, and offsets help to detect which ones under comparison are reliable, and offsets
the effect of anomalous replies. the effect of anomalous replies.
5. Reputation Service Providers 5. Reputation Service Providers
Operators intending to provide a reptuation service need to consider Operators intending to provide a reptuation service need to consider
that there are many flavors of clients. There will be clients that that there are many flavors of clients. There will be clients that
are prepared to make use of a reputation service blindly, while are prepared to make use of a reputation service blindly, while
others will be interested in understanding more fully the nature of others will be interested in understanding more fully the nature of
the service being provided. An operator of an RSP should be prepared the service being provided. These can be likened to a consumer
to answer as may of the questions identified in Section 4 as credit check that only seeks a yes-or-no reply versus wanting to
possible, not only because wise clients will ask, but also because review a detailed credit report. An operator of an RSP should be
prepared to answer as many 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 they reflect issues that have arisen over the years, and exploration
of the points they raise will result in a more robust reputation of the points they raise will result in a more robust reputation
service. service.
Obviously, in computing reputations via traffic analysis, some Obviously, in computing reputations via traffic analysis, some
private algorithms may come into play. For some RSPs, such "secret private algorithms may come into play. For some RSPs, such "secret
sauce" comprises their competitive advantage over others in the same sauce" comprises their competitive advantage over others in the same
space. This document is not suggesting that all private algorithms space. This document is not suggesting that all private algorithms
need to be exposed for a reputation service to be acceptable. need to be exposed for a reputation service to be acceptable.
Instead, it is anticipated that enough of the above details need to Instead, it is anticipated that enough of the above details need to
be available to ensure consumers (and in some cases, industry or the be available to ensure consumers (and in some cases, industry or the
general public) that the RSP can be trusted to influence key local general public) that the RSP can be trusted to influence key local
policy decisions. policy decisions.
Reptuations should be based on accurate identifiers, i.e., some Reptuations should be based on accurate identifiers, i.e., some
property of the content under analysis that is difficult to falsify. property of the content under analysis that is difficult to falsify.
For example, in the realm of email, the address found in the From: 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 header field of a message is typically not verifiable, while the
found in a validated domain-level signature is. In this case, domain name found in a validated domain-level signature is. In this
constructing a reputation system based on the domain name is more case, constructing a reputation system based on the domain name is
useful than one based on the From: field. more useful than one based on the From: field.
The biggest frustration with most RSPs to date has been the absence The biggest frustration with most RSPs to date has been the absence
of a visible, accessible, and transparent process for remediating the of a visible, accessible, and transparent process for remediating the
errant addition of an identifier to a negative reputation list. An errant addition of an identifier to a negative reputation list. An
RSP in widespread use is perceived to have enormous power when its RSP in widespread use is perceived to have enormous power when its
results are used to reject traffic outright; when a "bad" entry is results are used to reject traffic outright; when a "bad" entry is
added referencing a good actor, it can have destructive effects, so added referencing a good actor, it can have destructive effects, so
an effective mechanism to fix such problems needs to exist. an effective mechanism to fix such problems needs to exist.
To accommodate clients with varying sensitivities, it is advisable To accommodate clients with varying sensitivities, it is advisable
 End of changes. 15 change blocks. 
28 lines changed or deleted 35 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/