Telechat Review of draft-ietf-roll-building-routing-reqs-

Request Review of draft-ietf-roll-building-routing-reqs
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2009-09-22
Requested 2009-08-27
Authors Jerry Martocci, Pieter Mil, Nicolas Riou, Wouter Vermeylen
Draft last updated 2009-09-23
Completed reviews Secdir Last Call review of -?? by Derek Atkins
Secdir Telechat review of -?? by Derek Atkins
Assignment Reviewer Derek Atkins
State Completed
Review review-ietf-roll-building-routing-reqs-secdir-telechat-atkins-2009-09-23
Review completed: 2009-09-23



I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

   The Routing Over Low power and Lossy network (ROLL) Working Group has
   been chartered to work on routing solutions for Low Power and Lossy
   networks (LLN) in various markets: Industrial, Commercial (Building),
   Home and Urban networks. Pursuant to this effort, this document
   defines the IPv6 routing requirements for building automation.

First, this document has no section named "Security Considerations".
There is a "Security Requirements" sub-section (5.8) which looks like
it might be the "Security Considerations" section misnamed and poorly
placed in the document structure.

Second, the new "Security Requirements" sub-section matches the
contents of the "Security Considerations" section of version 05 of
this document, almost word-for-word.  Therefore my review from version
05 still applies.  Here is what I said:

> The Security Considerations appear to take into account various
> requirements for different systems.  What seems to be lacking is
> direction about how or when to apply various requirements and what
> it means to the deployment.
> For example, what would it mean to a deployment if it has
> authentication versus not having authentication?  Also, it's unclear
> how these requirements would apply to an implementor.
> Variable security policies is a good idea, but it requires more
> guidance because the end user will never understand the ramifications
> of choosing one policy over another.


       Derek Atkins                 617-623-3745
       derek at   
       Computer and Internet Security Consultant