Subject: [Roll] [roll] #78: Comments from R. Struik during WG LC of draft-ietf-roll-security-framework

From: "roll issue tracker" <[email-masked]>
Date: Mon, 06 Sep 2010 22:02:04 -0000

#78: Comments from R. Struik during WG LC of draft-ietf-roll-security-framework
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  tzeta.tsao@…                                                                             
     Type:  defect              |      Status:  new                                                                                      
 Priority:  major               |   Milestone:                                                                                           
Component:  security-framework  |     Version:                                                                                           
 Severity:  In WG Last Call     |    Keywords:                                                                                           
--------------------------------+-------------------------------------------
 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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/78>
roll <http://tools.ietf.org/wg/roll/>