Subject: [Roll] Some comments on draft-ietf-roll-security-framework-00

From: Rene Struik <[email-masked]>
Date: Mon, 06 Sep 2010 09:02:05 -0400

Please find below some comments on the IETF RoLL draft "A Security 
Framework for Routing over Low Power and Lossy Networks" 
(draft-ietf-roll-security-framework-00).

I did provide comments on an earlier version of this draft (before this 
was elevated from individual draft to working group draft), but did not 
check whether these have all been considered, so would encourage the 
authors to do so (and will be happy to work with them). Comments below 
are based on giving this a "fresh" look.

Section 2, l.1:
Networks could be compromised of any mixture of wireless and wired 
devices, since part of all communication links could be wired (an 
example of a partially wired network being one with a wireless sensor 
network that communicates to a wired back-end network via a gateway device).

Section 2, l.2-6:
The constraints include those on computational resources (RAM, clock 
speed, storage), communication resources (duty cycle, packet size, 
etc.), but also form factors that may rule out use of batteries (e.g., 
the housing of a small stick-on switch), or simply safety considerations 
(e.g., with gas meters).

Section 3, l. -1:
The security framework could potentially also be applied outside RoLL 
(cf. also Section 2 and Section 9). This brings to mind that it could be 
of interest to relate this effort to IETF draft 
draft-ietf-opsec-routing-protocols-crypto-issues-07, which discusses 
routing security issues as well.

Section 3.1:
Simplistically, security entails implementing measures to ensure 
controlled state changes on devices and networks only, both based on 
external inputs (received via communications) or internal inputs 
(physical security of device itself and parameters maintained by the 
device, including, e.g., clock). State changes would thereby involve 
proper authorization for actions, authentication, (potentially) 
confidentiality), but also proper order of state changes, and, e.g., 
timeliness (for seriously delayed state changes, such as commands or 
updates of routing tables, may negatively impact system operation).

Section 3, 3rd para:
Some routing attacks could be viewed as misrepresenting routing topology 
(e.g., device closeby/far-off).

Section 3.1, Fig. 1:
One should perhaps separate route establishment and rout maintenance.

Section 3.2:
The description of "integrity" seems to encompass authorization as well 
(l. 6-8). It may be useful to introduce data authenticity (and mention 
that non repudiation provided by signatures may not be that useful for 
sensors, but using signatures for source authentication in multicast 
settings may be). Furthermore, one may benefit from emphasizing that one 
complements security constructs with security policy enforcement 
mechanisms (authorization, possibly depending on device role, etc.; 
acceptance of incoming msgs dependent on policy checks, etc.).

Section 3.4, 2nd para below bulletized list, l.3:
This reiterates the importance of timeliness aspects.

Sectionj 3.4, l. -1:
"may be compromised and countered" should read "may be compromised and 
how this potential compromise is countered".

Section 6:
Currently, the relationship between Section 6 and Sections 4 and 5 
(threat and countermeasure sections) is rather weak, since it seems one 
can correlate Section 6 to Section 3.4 instead and skip over Sections 4 
and 5 (esp. given knowledge of the survey paper by Wagner and Karlof 
[Karlof2003]).

Section 11.2:
The references may need updating, since most RoLL-related drafts have 
seen revisions (or issued as RFC document) since the time of publication 
of the current draft on March 30, 2010.

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658