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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg