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.