Operational Considerations Regarding Reputation Services

The information below is for an old version of the document
Document Type Active Internet-Draft (repute WG)
Author Murray Kucherawy 
Last updated 2013-02-26 (latest revision 2012-11-09)
Replaces draft-kucherawy-repute-considerations
Replaced by draft-kucherawy-repute-consid
Stream Internet Engineering Task Force (IETF)
Formats pdf htmlized bibtex
Stream WG state WG Document
Document shepherd Chris Lewis
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
REPUTE                                                      M. Kucherawy
Internet-Draft                                          November 8, 2012
Intended status: Informational
Expires: May 12, 2013

        Operational Considerations Regarding Reputation Services


   The use of reputation systems is has become a common tool in many
   applications that seek to apply collected intelligence about traffic
   sources.  Often this is done because it is common or even expected
   operator practice.  It is therefore important to be aware of a number
   of considerations for both operators and consumers of the data.  This
   document includes a collection of the best advice available regarding
   providers and consumers of reputation data, based on experience to
   date.  Much of this is based on experience with email reputation
   systems, but the concepts are generally applicable.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 12, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Kucherawy                 Expires May 12, 2013                  [Page 1]
Internet-Draft            Reputation Operations            November 2012

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Reputation Clients  . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Reputation Service Providers  . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7

Kucherawy                 Expires May 12, 2013                  [Page 2]
Internet-Draft            Reputation Operations            November 2012

1.  Introduction

   Reputation services involve collecting feedback from the community
   about sources of Internet traffic and aggregating that feedback into
   a rating of some kind.  Common examples include feedback about
   traffic associated with specific email addresses, URIs or parts of
   URIs, IP addresses, etc.  The specific collection, analysis, and
   rating methods vary from one service to the next and one problem
   domain to the next, but several operational concepts appear to be
   common to all of these.

   The promise of the protection that reputation services offers can be
   enticing, and many users and operators alike typically engage those
   services merely because it is expected of them.  A critical notion,
   however, is that doing so explicitly involves a third party in the
   flow of data those parties receive.  This is often taken for granted,
   with potentially disastrous results.

   This document highlights this and other considerations in providing
   and consuming reputation data services.

2.  Background

   The community has historically focused on identifying sources that
   misbehave, i.e., that earn negative reputations.  The purpose here is
   to identify and filter traffic from bad actors.  This grew out of
   operational need.  As the Internet grew, so did the occurence of
   problematic traffic, especially in email.  The pragmatics of email
   (i.e., the fact that the total IP address space is more constrained
   than the total email address space) drove the focus on using IP
   addresses as the focus of reputation, in addition to the fact that IP
   addresses have a degree of validation (via the TCP/IP infrastructure)
   where email addresses have had none.

   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
   database as to whether a source of incoming [SMTP] email traffic
   should be allowed to relay email, based on previous observations and
   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
   interface.  [DNSBL] includes several points in its Security
   Considerations document that are repeated and further developed here.

   However, regardless of the identifier used as the identifier for a
   reputation, bad actors can evade detection or the effects of their
   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 May 12, 2013                  [Page 3]
Internet-Draft            Reputation Operations            November 2012


3.  Evolution

   More modern thinking is evolving toward the identification of good
   actors rather than bad actors, and giving them preferential
   treatment.  This drastically reduces the problem space: There are
   vastly more IP addresses and email addresses used by bad actors to
   generate problematic traffic than are used by good actors to generate
   desirable traffic.

   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.

   This notion has only been tried to date using manually edited
   whitelists, but has shown promising results on that scale.

4.  Reputation Clients

   understand that you are granting a third party the ability to affect
   your incoming traffic, for better or worse

   this is the point, of course, when everything works properly

   some cases have occurred where a reputation service provider (RSP)
   shut down operation, and to encourage consumers to stop querying, it
   began reporting a maximal negative reputation about all subjects,
   causing rejection of all incoming traffic during the incident period

   reputation providers will be the subject of attacks when it's
   understood that sucess doing so will allow malicious content to evade
   detection and filtering; clients need to be aware of possible
   interruptions in service availability or quality

   understand that some actors will try to game the service, which means
   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
   exposure potential:

   o  their basis for listing or not listing particular subjects

Kucherawy                 Expires May 12, 2013                  [Page 4]
Internet-Draft            Reputation Operations            November 2012

   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  how many data points are input to the reported reputation

   o  is reputation based on a reliable identifier?

   o  how it etablishes reliability and authenticity of those data

   o  how data validity is maintained (e.g., on-going monitoring of the
      reported data and sources)

   o  how actively data validity is tracked (e.g., how changes are

   o  how disputed reputations are handled

   o  how data expire

   o  is older information more or less influential than newer?

   o  is the reported reputation a scalar, a Boolean value, a collection
      of values, or something else?

   o  when transitioning among RSPs, determine the differences between
      them among these above points; that is, does a particular score
      from one mean the same thing from the other?

   ensure the capability of 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
   acceptance; for example, rather than rejecting content outright when
   a negative reputation is returned, simply subject it to additional
   local analyis

   have a sensible default to apply when the RSP is not available

   consider tailoring operation to prefer or emphasize content whose
   sources have positive reputations; recall that negative reputations
   are easy to shed, and the universe of things that will earn and
   maintain positive reputations is relatively small

   consider querying and cross-referencing multiple RSPs; this helps to
   detect which are reliable, and offsets the effect of anomalous

Kucherawy                 Expires May 12, 2013                  [Page 5]
Internet-Draft            Reputation Operations            November 2012

5.  Reputation Service Providers

   make the answers to the questions in Section 4 available on demand to

   base reputations on accurate identifiers, i.e., something difficult
   to forge

   it is important to have a transparent remediation process for
   disputes of computed reputations

   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, such as:

   o  the result itself

   o  the number of data points used to compute the result

   o  the age range of the data

   o  source diversity of the input data

   o  currency of the result (i.e., when it was computed)

   o  basis of the result (i.e., which identifier was used)

   harden systems and algorithms as much as practicable against gaming
   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
   reputations, if made difficult to earm put a large cost on bad actors

6.  Security Considerations

   Several points are raised above that can be described as threats to
   the delivery of valid user data.  This document highlights and
   discusses those issues, but introduces no new security issues.

7.  IANA Considerations

   This memo contains no actions for IANA.

   [RFC Editor: Please remove this section prior to publication.]

Kucherawy                 Expires May 12, 2013                  [Page 6]
Internet-Draft            Reputation Operations            November 2012

8.  Informative References

   [DNS]    Mockapetris, P., "Domain Names -- Concepts and Facilities",
            RFC 1034, November 1987.

   [DNSBL]  Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
            February 2010.

   [SMTP]   Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
            October 2008.

Appendix A.  Acknowledgements

   The author wishes to acknowledge the following for their review and
   constructive criticism of this proposal: (names)

Author's Address

   Murray S. Kucherawy

   EMail: superuser@gmail.com

Kucherawy                 Expires May 12, 2013                  [Page 7]