[Gen-art] Gen-ART review of draft-ietf-opsec-current-practices-07.txt

"Gray, Eric" <Eric.Gray@marconi.com> Wed, 27 September 2006 21:34 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSh2j-0006Ll-UW; Wed, 27 Sep 2006 17:34:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSh2i-0006Lg-5s for gen-art@ietf.org; Wed, 27 Sep 2006 17:34:12 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSh2f-0004QJ-OO for gen-art@ietf.org; Wed, 27 Sep 2006 17:34:12 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k8RLY5ca017640; Wed, 27 Sep 2006 17:34:05 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA27036; Wed, 27 Sep 2006 17:34:05 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJM9DM0>; Wed, 27 Sep 2006 17:34:04 -0400
Message-ID: <0BF76B30C100624BA997C9CED19D81257D4A8C@uspitsmsgusr08.win.marconi.com>
From: "Gray, Eric" <Eric.Gray@marconi.com>
To: Merike Kaeo <merike@doubleshotsecurity.com>
Date: Wed, 27 Sep 2006 17:34:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186
Cc: David Kessens <david.kessens@nokia.com>, gen-art@ietf.org
Subject: [Gen-art] Gen-ART review of draft-ietf-opsec-current-practices-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

Merike,

	I am the Gen-ART assigned reviewer for this draft: 

		draft-ietf-opsec-current-practices-07.txt

	For background on Gen-ART, please see the FAQ at:

	http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html

	Please wait for instruction from the applicable Area
Director prior to taking any action on these comments.

Summary:
=======

This draft is nearly ready for publishing as an Informational
RFC. Minimally, it needs a good grooming for editing mistakes.
In fairness, most of the editing mistakes I noted occur in the 
up-front text sections (introduction, etc.) that may not have 
been thoroughly reviewed recently.

This is a very useful work and I am glad to have had a chance
to look it over in detail.

Comments:
========

General comment(s) -
------------------

The introduction says that the draft is based on a survey. It 
would be useful to include a few generic statistics about the
survey: when was it conducted, how many responses were received,
other non-compromising information of that nature. 

I am not sure why we include L2 in the ID's scope (section 1.1)
- you mention IPv4 and IPv6, but the document seems to ignore L2
security in at least a few key points.  There is - for example
- no mention of specific L2 technology information (as there is
for L3).  Also, some of the attack information appears to omit
discussion of variations of attacks that apply to L2 networks.

Section 1.2 ("Threat Models") -
-----------------------------

Not all "attacks" are against "system security" - in fact, from a
user perspective, attacks against "system security" matter only
to the extent that they induce a "system security" failure (either
directly, or as a distraction result).  It seems to me that only
attacks which affect availabilty of services, or confidentiality
of information, can be deemed "successful" - although there is 
certainly room to include un-authorized use (even if it does not
affect availability).  As an analogy, someone's being in my yard
without my permission is not a violation of my fences (or - in
my case - stone walls).

Section 2.2.1 ("Threats / Attacks") - 
-----------------------------------

I am not sure that I agree that "a topology subversion is required 
to reroute traffic and essentially bring the attacker on-path" - 
at least not within the L2/L3 scope of this draft.  I believe a
re-direction can be created through misrepresentative service
advertisements at higher layers (not subverting L2/L3 topology at
all) - such as occurs in phishing attacks.

Section 2.3.4 ("Additional Considerations") - 
-------------------------------------------

On the topic of rate limiting, you make the statement "some [...]
ISPs believe [rate limiting] is not really useful since attackers 
are not well behaved ([paraphrased]).  What does this mean?  Is it
a reference to congestion avoidance?  Can we make this explicit?

NITs:
====

Section 1.2 ("Threat Models") -
-----------------------------

Last sentence (starting with "Many of the threats to a network 
infrastructure occur ...") - "a network infrastructure" seems
awkward.  Perhaps "network infrastructure" or "a network"?

Second paragraph (ending with "vulnerabilities") needs a period.

Fourth paragraph - "Protocol Vulnerability Exploitation: An 
attack which takes advantage of known protocol vulnerabilities 
due to design or implementation flaws to cause inappropriate 
behavior" - the phrase "due to design or implementation flaws"
appears to be parenthetical (and should be parenthesized).

Fifth paragraph ("Message Insertion") - "reply" should be 
"replay" (wording of this parenthesized phrase is extremely 
awkward - containing the word "which" twice, omitting an
article, etc.).  Suggest instead:

"(for example - a replay attack, which is a scenario where a 
 message is captured and resent at a later time)."

Seventh paragraph ("Message Modification") - this definition
is awkward for several reasons.  According to what I've been
told by security experts, a man-in-the-middle attack is not
an attack until a message modification occurs (eavesdropping
is itself not a MITM attack) - consequently (for the MITM
case), a message could be captured as part of a MITM attack
(as opposed to "using a [MITM] attack").  Also, as worded now,
the definition seems to exclude message modification as part 
of a "replay" attack variation.  Finally, message modification
seems to be part "Insertion" and part "Diversion/Deletion" - 
as opposed to being "a subset of a message insertion attack".

I believe that - in the last paragraph of section 1.2 - you 
want to say "sometimes Denial of Service is listed as a 
separate attack category."

Section 1.3 -
-----------

When you say "can be sourced" do you mean "can originate"
or "can be categorized" (I suspect the latter)?  The subject
matter does not seem to agree with the section name.  Perhaps
the section name should be "Attack Categories"?  This comment
(or question) applies generally to this section as you refer
to attack "sources" in at least one other place in this 
section.

The specific examples you list for "passive attacks" all
start as "active attacks."  This could be construed as an
implication that purely passive attacks do not exist. Since 
you include L2 security in the scope for this ID, you could 
include L2 snooping - or promiscuous listening - on shared
access networks as a purely passive form of attack.  This 
goes to whether or not you should be including L2 security 
in the scope for this ID (see general comments above).  Also, 
a device that is located in the same subnet with IGP routing 
devices can usually passively snoop on IGP routing traffic.

In the last sentence in the sub-section entitled "On-path vs 
off-path attacks" - I cannot determine the purpose for the
citing of RFC 3552 ("Guidelines for Writing RFC Text on 
Security Considerations") at the beginning of this sentence.

Suggest omitting "or illegitimate" from the last sentence of
the sub-section entitled "Insider or outsider attacks".

In sub-section entitled "Deliberate attacks vs unintentional 
events" - you should use "perpetrator" instead of "miscreant"
as a deliberate attack might occur legitimately (as a result
of testing of network security, for example, and not be at
all criminal, malicious or heretical).  :-)

Note: you use the term miscreant elsewhere in what appears to
be a correct manner, so it is just this instance that might
need to be changed.

Section 1.5 -
-----------

Last sentence in the section, suggest rewording "due to bugs
or lack of ease of use" to something like - "due to bugs or
insufficient ease of use."

Section 2.2 - 
-----------

Last sentence needs a period.

Section 2.4.2 - 
-------------

The list of included BGP routing policies would be easier to 
read as a list (with bullets) - as follows:

"These include: 

 o	incoming and outgoing prefix filters for BGP customers, 
 o	incoming and outgoing prefix filters for peers and 
	upstream neighbors, 
 o	incoming AS-PATH filter for BGP customers,
 o	outgoing AS-PATH filter towards peers and upstream 
	neighbors, 
 o	route dampening and rejecting selected attributes and 
	communities."

Section 2.4.4 -
-------------

I think the last two words in the first paragraph should be
"vendors' products" instead of "vendors products'" (single
quote/apostrophe relocated).  Alternatively, it could simply
be "vendor products."

Section 2.5.1.4 - 
---------------

The phrase "unbeknownst to them" is (I believe) parenthetical
(and should be parenthesized).  It is difficult to parse the
entire sentence without first determining where the "pauses" 
should occur in reading it.






_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art