Recommendations for the Remediation of Bots in ISP Networks
draft-oreirdan-mody-bot-remediation-20

[Ballot comment]
Good document. All my comments are related to Section 5:

1.

> It should be possible for the end user to indicate the preferred
  means of notification on an opt-in basis for that notification
  method.  It is recommended that the end user should not be allowed to
  totally opt out of notification entirely.

It looks like either 'totally' or 'entirely' is redundant

2. I would expect notifications by management protocols like SNMP and NETCONF be also described in this section

3. The danger of DoS attacks by flasely reporting of bots via notifications shoulsd also be mentioned as a major security concern

[Ballot comment]
Minor comments:

Section 1.3 - Do we really need to define the word host

Section 1.5 - When IPv6 takes off, you will see fast-flux using AAAA records

[Ballot comment]
1.1 - I have never heard of "benign bots" before. Is this an invention of the authors or is it used in some circles? I would prefer if the document referred to only the malicious applications as "bots" and referred to the benign applications as "background applications" or "daemons" or "background processes". I think it is still important to point out that such applications should not be monitored for or prevented from functioning.

1.2 - "Bot Networks or Botnets" is better defined as "a group of bots that are remotely controlled by a single party". The first sentence of 1.2 is circular.

I know what all of those malicious activities are, but it might be useful to define some of them.

"Infection vectors" is undefined. So are a bunch of the terms in that paragraph.

Much of this section assumes a familiarity by the reader. If the reader was this familiar with the material, this section wouldn't be necessary. Similarly with 1.4.

1.5 - The information in the two paragraphs is reversed, burying the important point: Compromised hosts are used as proxies to web servers in order to hide the IP address of the server itself. This is *accomplished* by DNS Fast Fluxing.

10. - Some of the activities outlined in section 3 should be called out specifically with regard to privacy considerations.

A reference to RFC 4948 seems pretty essential. I'm surprised not to see some of the information that appears in that document in this one.

[Ballot comment]
Thanks for a very readable document with a lot of valuable information.

I have a few small conversation topics that I would appreciate you
thinking about and addressing if you can see a way forward.

---

I am surprised by the statement in the Abtract that a user with an
infected computer is exposed to the risk of phishing. Te seond statement
that their computer might be used as an inadvertent participant in a
phishing network sounds more reasonable.

---

I wonder whether Section 5 needs to consider the risks of notifications
after false positives, and the problems caused by false notifications
as a form of attack.

---

Section 7 upset me a little. Recognising the need of ISPs to protect
their businesses, I also see the need to continue to provide servie to
vulnerable people who cannot be expected to protect their computers.

In view of this, you might discuss the service providers' duty to ensure
that hosts connected to their network cannot become infected with bots
through data transfered across the service providers' networks. Or you
might just drop the text about account termination.

[Ballot comment]
This is a good document.  I am not at all an expert in this area, but my only comment is that it seems like there may be some liability to the ISP in attempting to detect bot infections because they may then need to bear the burden to report criminal activity that they witness.  I'm sure commercial ISPs have considered this in their policies, but I didn't notice it clearly mentioned in the document.

[Ballot comment]
Overall this is a helpful document. I have a few comments and suggestions.

In Section 1.2:

OLD
  The detection and
  destruction of bots is an ongoing issue and also a constant battle
  between the Internet security community, network security engineers
  and bot developers.

NEW
  The detection and
  destruction of bots is an ongoing issue and also a constant battle
  between the Internet security community and network security
  engineers on the one hand and bot developers on the other.

P2P is not a communication protocol, it is an architectural approach.

It is a bit odd to speak of the "introduction" of HTTP, given that HTTP was invented over 20 years ago.

The document sometimes conflates bots and botnets. For example:

  As a consequence, botnets that are initially detected
  and classified by the ISP as one particular type of bot need to be
  continuously monitored and tracked in order to identify correctly the
  threat the botnet poses at any particular point in time.

Although a botnet consists of bots, not all bots are part of a botnet (and we certainly can't say that a botnet can be classified as a type of bot, as in the quoted paragraph).

[Ballot comment]
There is the outstanding issue of verifying that the IPR issues noted by the Shepherd have been fully resolved. I am sure that Stephen will verify the resolution before issuing a publication request, and thus am highlighting this issue as a comment.

=====

"An ISP may use Netflow [RFC3954]"

I would think that the the standards based solution  IPFIX [RFC5101] would be a better reference.

=====

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Recommendations for the Remediation of Bots in ISP Networks) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Recommendations for the Remediation of Bots in ISP Networks'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document contains recommendations on how Internet Service
  Providers can manage the effects of computers used by their
  subscribers, which have been infected with malicious bots, via
  various remediation techniques.  Internet users with infected
  computers are exposed to risks such as loss of personal data, as well
  as increased susceptibility to online fraud and/or phishing.  Such
  computers can also become an inadvertent participant in or component
  of an online crime network, spam network, and/or phishing network, as
  well as be used as a part of a distributed denial of service attack.
  Mitigating the effects of and remediating the installations of
  malicious bots will make it more difficult for botnets to operate and
  could reduce the level of online crime on the Internet in general
  and/or on a particular Internet Service Provider's network.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-oreirdan-mody-bot-remediation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-oreirdan-mody-bot-remediation/


No IPR declarations have been submitted directly on this I-D.

Elwyn Davies' PROTO write up for this below.

Document Shepherd write up for draft-oreirdan-mody-bot-remediation-16

    (1.a)
        Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?
                Elwyn Davies
                I have personally reviewed the document and believe that it is ready for forwarding to the IESG.
 
    (1.b)
        Has the document had adequate review both from key members of the interested community and others? Does the  Document Shepherd have any concerns about the depth or breadth of t= he reviews that have been performed?
                Although this is an individual submission, the document has been reviewed in  The Messaging Anti-Abuse Working Group (MAAWG) (http://www.maawg.org).  The draft  represents an update of a document published by the MWAAG in 2009 (Common Best Practices for Mitigating Large Scale Bot Infections in Residential Networks -  http://www.maawg.org/sites/maawg/files/news/MAAWG_Bot_Mitig ation_BP_2009-07.pdf).
                The draft also lists 25 individuals who have contributed to or reviewed the document some of whom are well known in the IETF. There is also significant membership overlap between the MWAAG and the IETF.  The document has been discussed on= the OPSEC mailing list.
                Some review has also been received on the SAAG mailing list.
                Thus I believe that the document has been adequately reviewed.

    (1.c)
        Does the Document Shepherd have concerns that the document needs mo= re review from a particular or broader perspective, e.g., security, operational complexity, someone famili= ar with AAA, internationalization or XML?
                No.  (1.d)
        Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area  Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts  of the document, or has concerns whether there really is a need for it. In any event, if the interested  community has discussed those issues and has indicated that it still wishes to advance the document, detail  those concerns here.
                Technically I am happy with the document.  The only concern that I had regards IPR.  The main body of the document is an update of a document published by the MWAAG and as such shares much of its text with the MWAAG document mentioned at 1.b.  The documents  have common authors.  The MWAAG claims copyright on their document.  Thus the copyright position of the Internet Draft needs to be clarified.  I understand that the authors of the MWAAG document have indicated that they are happy for the text to be published as an RFC.  In all probability a fomal statement will be needed from the MWAAG.
               
                Arguably the document could be put forwards in the BCP cate= gory as opposed to Informational.
               
    (1.e)
        How solid is the consensus of the interested community behind this  document? Does it represent the strong  concurrence of a few individuals, with others being silent, or does the interested community as a whole  understand and agree with it?  Judging from the membership roster of the MWAAG, the concensus appears to be solid.
               
    (1.f)
        Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.
                No.
               
    (1.g)
        Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type  and URI type reviews?
                ID Nits - OK (Need to check IPR issue)
                No other sorts of review are relevant.
    (1.h)
        Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an= unclear state? If such normative references  exist, what is the strategy for their completion? Are there normative references that are downward references,  as described in [RFC3967] (Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer  Normatively to Documents at a Lower Level," December 2004.)? If so, list these downward references to support  the Area Director in the Last Call procedure for them [RFC3967] (Bush, R. and T. Narten, "Clarifying when  Standards Track Documents may Refer Normatively to Documents at a L= ower Level," December 2004.).
                The document is informational.  All references are correctl= y classed as informative.
               
    (1.i)
        Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with  the body of the document? If the document specifies protocol extens= ions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new  registry, does it define the proposed initial contents of the registry and an allocation procedure for future  registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG  can appoint the needed Expert during the IESG Evaluation?
                Yes (No IANA actions required).
    (1.j)
        Has the Document Shepherd verified that sections of the document that are written in a formal language, such as  XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?
                Yes - No such sections present.
               
    (1.k)
        The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document  Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The  approval announcement contains the following sections:
 
        Technical Summary

            This document contains recommendations on how Internet Service
            Providers can manage the effects of computers used by their
            subscribers, which have been infected with malicious bots, via
            various remediation techniques.  Internet users with infected
            computers are exposed to risks such as loss of personal data, as well
            as increased susceptibility to online fraud and/or phishing.  Such
            computers can also become an inadvertent participant in or component
            of an online crime network, spam network, and/or phishing network, as
            well as be used as a part of a distributed denial of service attack.
            Mitigating the effects of and remediating the installations of
            malicious bots will make it more difficult for botnets to operate and
            could reduce the level of online crime on the Internet in general
            and/or on a particular Internet Service Provider's network.

        Working Group Summary

            N/A - This document is an Individual Submission sponsored by an= Area Director.

        Document Quality

            The document reflects accepted best practice promulgated by The Messaging  Anti-Abuse Working Group (MAAWG) (http://www.maawg.org) outside the IETF.  The document has been reviewed on the IETF OPSEC mailing list notably by Joel Jaeggli and Danny McPherson among others.

        Personnel

            Document Shepherd: Elwyn Davies
            Responsible/Sponsoring Area Director: Stephen Farrell

State Change Notice email list has been changed to elwynd@folly.org.uk, jason_livingood@cable.comcast.com, nirmal_mody@cable.comcast.com, michael_oreirdan@cable.comcast.com, draft-oreirdan-mody-bot-remediation@tools.ietf.org from jason_livingood@cable.comcast.com, nirmal_mody@cable.comcast.com, michael_oreirdan@cable.comcast.com, draft-oreirdan-mody-bot-remediation@tools.ietf.org