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

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.

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

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.

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).

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.

=====