Re: [Asrg] Request for Feedback: draft-oreirdan-mody-bot-remediation-03

[Alessandro Vesely <[e-mail]>]

Mody, Nirmal wrote:
> We are looking for feedback on draft-oreirdan-mody-bot-remediation-03.
> URL:  http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03

I think this bot-remediation I-D might be better coordinated with the 
RID, http://tools.ietf.org/html/draft-moriarty-post-inch. Since 
"[d]etection of a security incident is outside the scope of [the 
latter] paper", they complement one another. In particular, the former 
paper misses a definition of ISP, which is less ambiguously termed 
"network provider (NP)" in the latter.

The definition of "Computer" given in 2.3 apparently limits the scope 
of the I-D to end-user appliances, i.e. not servers. Although that's 
consistent with the Problem Statement, it might be worth repeating it 
in section "4. Important Notice of Limitations and Scope".

In section "2.4 Malware", I'd reword this snippet

  This is short for malicious software.  In this case, malicious bots
  are considered a subset of malware.  Other forms of malware could
  include viruses and other similar types of software.

to make a clearer definition, e.g. as

  This is short for malicious software.  The bots we consider are a
  subset of malware.  Malware also includes viruses, Trojans, spyware,
  adware, and similar types of software.

In the successive snippet

  Alternatively, Internet-connected computers may become infected with
  malware through externally initiated malicious activities such as the
  exploitation of vulnerabilities or the brute force guessing of access
  credentials.

I would also mention that an attacker may already know the password 
(but doesn't this involve servers?) E.g.

  Alternatively, Internet-connected computers may become infected with
  malware through externally initiated malicious activities such as the
  exploitation of vulnerabilities, the brute force guessing of access
  credentials, or the exploitation of such credentials obtained at a
  previously compromised computer.

The second paragraph in section "5. Detection of Bots" is very long 
and difficult. In particular, in this sentence

                  It is likely that a combination of multiple bot
  detection data points will prove to be an effective approach in order
  to corroborate information of varying dependability or consistency,
  as well as to avoid or minimize the possibility of false positive
  identification of computers.

it is not clear what is a "data point"? I guess you are talking about 
data interchange between ISPs, as detailed in the above mentioned RID.

The same paragraph again talks about bots that are "malicious in 
nature", a concept that I fail to understand. The I-D never talks 
about ascertaining whether a user knows about the bot and accepts 
accountability for its actions, which would classify it as non-malware.

The section continues with items (a) through (g). I'd suggest 
converting them to subsections, for better quoting and pointing to 
them. Only a couple of those items are relevant for mailbox providers; 
should that be noted?

I'm surprised about item (f)

  f.  ISPs may also discover likely bot infected hosts located at other
      sites; when legally permissible or otherwise an industry accepted
      practice in a particular market region, it may be worthwhile for
      ISPs to share evidence relating to those compromised hosts with
      the relevant remote ISP, with security researchers, and with
      blocklist operators.

I assume it is about firewall-detected scans, attempts to access 
closed ports, well known URIs, as well as dictionary attacks, and 
similar. If there really exist laws that forbid to notify such 
intrusion attempts to the relevant abuse mailbox, they are wrong and 
the IETF should lobby the relevant governments for abrogating them...

The title of section "6.2. Telephone Call Notification" might perhaps 
be changed to "Telephone or Fax Call Notification". In particular, fax 
numbers are more often answered by computers.

In section "6.4. Walled Garden Notification", it may be worth to 
mention IP fingerprinting as a possible disambiguation for NATted 
hosts, as described, e.g., in 
http://www.rbeverly.net/research/papers/tcpclass-pam04.html 
http://www.sflow.org/detectNAT/. This concern is addressed in section 
7 ("diligence needs to be taken by the ISP where possible such that 
they can identify") so a "see also" might be needed.

In section 7, the sentence
                                                     This security web
  site should clearly explain why the user was notified and may include
  an explanation of what bots are, and the threats that they pose.

assumes that the ISP is tightly coordinated with the provider of the 
security web site. I only note that section 7 should be of interest 
also for standalone computer servicing shops' web sites.

The text suggested for explanation ("What is a bot? [...]") does not 
mention that the user may be held legally accountable for any damage 
that the bot may perpetrate.

The paragraph of section "9. Security Considerations" sounds to me 
like "since this doc is all about security, this section only exists 
for accomplishing formal RFC requirements." IMHO, in this context, it 
would be more useful to recap the risks of phishing by notifying false 
infections, and to collect the passages where PII is concerned.

Finally, a few typos

s/solical/social/
s/poses can pose/can pose/
s/Compters/Computers/

HTH