Subject: [Gen-art] Gen-ART review of draft-ietf-roll-security-framework-03

From: <[email-masked]>
Date: Mon, 27 Dec 2010 23:13:58 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-roll-security-framework-03.txt
Reviewer: David L. Black
Review Date: December 27, 2010
IETF LC End Date: December 30, 2010
IESG Telechat date: January 6, 2011

Summary: This draft is on the right track, but has open issues, described in the review.

This is a security framework draft that sets out a security framework for routing in low power and lossy networks starting from the tripartite CIA (Confidentiality, Integrity, Availability) set of security properties.  While the draft is well-written, its security reasoning is incomplete.  For each of the C, I, and A areas, Section 4 lacks an argument that the listed threats and attacks are comprehensive.  In general, there is no linking of the threats and attacks to the listed assets and points of access (attack/threat targets) in Section 3.1.  

In addition, there are specific problems in each of the three areas:  

(1) The Confidentiality portion (section 4.1) is missing material on sniffing and traffic analysis, plus there is no argument made that deliberate exposure, sniffing and traffic analysis cover all means of breaching confidentiality.  Beyond that, a definition of "deliberate exposure" would help - I'm inferring active malicious action by privileged actor that exposes confidential information.

(2) The Integrity portion (section 4.2) omits at least remote device access for compromise as a complement to physical device access, and for some reason, does not consider the forwarding table (output of the routing protocol) as a target of threats/attacks.

(3) The Availability portion (section 4.3) fails to consider response to communication degradation or partial loss of connectivity.  An attacker may be able to selectively impede or disable communication (e.g., deploy electromagnetic interference near a subset of the wireless nodes).  In general, a routing protocol should have a robust response to partial loss of communication/connectivity, but within defined limits (obviously a routing protocol is helpless against an attacker who can disable all inter-node communication).

The requirements specified in Section 6 have a number of issues:
- There is no discussion of why each requirement is specified as 	MUST, SHOULD
	or MAY.
- The draft does not distinguish requirements for implementation from requirements
	for usage (e.g., "MUST implement" & "MAY use" is a reasonable combination).
- The confidentiality and privacy requirements are SHOULD.  Unless there is a
	good reason not to do so, they both should be "MUST implement" (use can
	be configured and/or negotiated).  This is an example of failure to
	distinguish implementation and usage requirements.
	problem in the draft, in that it fails to distinguish 
- Section 6.5.1 contains some badly worded language on p.36 about routing protocols
	inheriting the security properties of link level security for the links used.
	The word "automatically" needs to be removed, and the text rewritten to
	refer to security protocols instead of stating that use of AES and SHA-1
	algorithms suffice for confidentiality and integrity protection.  In case
	it's not clear, they do not suffice:
		- AES in ECB mode is weak, independent of key size.
		- SHA-1 by itself is not a secure integrity check; it needs
			to be keyed, and the details of how the key is used matter.
- In my view, the near dismissal of all countermeasures to Byzantine attacks on
	p.37 is flawed.  While the draft is correct that comprehensive countermeasures
	to Byzantine attacks are difficult and potentially time/resource-consuming,
	I believe the draft should recommend some common-sense sanity checks on
	received data.  A common form of Byzantine attack is administrative mis-
	configuration; a reasonable level of sanity checks on received routing
	data could help detect such mis-configurations before they cause serious
	damage.

Section 7 of the draft feels short, weak and incomplete to me.  It should either
be significantly expanded or removed.

Nits:

Last paragraph in 3.2 is very general to the level of boilerplate.

In section 3.3's discussion of highly directional traffic, the use of "low route cost" assumes a cost or weight based routing.  Use of the phrase "preferred route" would be more general.

Section 3.4, across the bottom of p.12 and the top of p.13 - this asserts that topology is not and cannot be confidential in practice.  I think this was written too quickly.  Topology info can clearly be kept confidential from a passive attacker who only listens to traffic, but cannot be kept confidential from insider attack where the adversary has compromised a node authorized to participate in routing.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------