Subject: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07

From: Derek Atkins <[email-masked]>
Date: Sat, 19 Sep 2009 19:28:12 -0400

Hi,

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

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Adrian Farrel <[email-masked]>
Date: Sun, 20 Sep 2009 11:00:08 +0100

Hi Derek,

I very much appreciate your review.

It is important to understand that this document specifies requirements that 
must/should/etc be satisfied by a protocol designed by the working group. 
Thus, there is no question of what should be deployed or what should be 
implemented.

That is, the document specifies what must be in the protocol spec. We can 
expect the protocol spec to discuss what must be implemented. And either the 
protocol spec or an applicability statement would describe what must be 
deployed.

So, the concerns you raise would be very important in the final protocol 
spec (and I hope the chairs and authors are paying attention), but do not 
seem to me to fit in this document.

Thanks,
Adrian

---

From: [email-masked]
Date: Mon, 21 Sep 2009 10:59:52 -0500

Hi Derek,

As the author of the document, I am trying to describe in this 
requirements ID the flexibility of setting up the security policies (as 
Adrian notes) rather then the application specifics of picking a security 
policy for a given application.  Earlier versions of this ID included this 
information, but was dropped since it was out of scope for the routing 
protocol. 

I have recently been requested to draft an ID for the 6LowAPP that would 
deal specifically with Building Applications at the application layer 
rather than at the routing layer.  Here, I intend to reinject into this 
new ID specificity as to when different security strategies are required. 
I have attached a spreadsheet that describes 5 different security policies 
(rows) that must be configurable for many different types of commercial 
buildings with the varying requirements for each building type (columns). 
I intend to redraft this spreadsheet into a section of the ID. 

I hope this is more of what you're looking for and can accept that I will 
put is into a separate ID.  If you think any of this should be put into 
the existing requirements ID, let me know and I will add it in.

Best Regards,

Jerry Martocci

Adrian Farrel <[email-masked]> 
09/20/2009 05:00 AM
Please respond to
Adrian Farrel <[email-masked]>

To
Derek Atkins <[email-masked]>, [email-masked], [email-masked]
cc
[email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
Subject
Re: sec-dir review of draft-ietf-roll-building-routing-reqs-07

Hi Derek,

It is important to understand that this document specifies requirements 
that 
must/should/etc be satisfied by a protocol designed by the working group. 
Thus, there is no question of what should be deployed or what should be 
implemented.

That is, the document specifies what must be in the protocol spec. We can 
expect the protocol spec to discuss what must be implemented. And either 
the 
protocol spec or an applicability statement would describe what must be 
deployed.

Thanks,
Adrian

---

From: Derek Atkins <[email-masked]>
Date: Wed, 23 Sep 2009 10:26:32 -0400

Hi,

First, I do think you need to change the structure and re-introduce the
"Security Considerations" section.

Second, I think it's important (even in a requirements document) to
explain the ramifications of different security tradeoffs.

I agree that you don't need to specify "Use AES-256 in GCM mode" in this
document.  However I do think you need to go into more detail about the
various security services that your protocols will need to define, and
the trade-offs that might happen if they choose to define it one way
versus another.  In other words, what are the security requirements for
your sub-protocols?

I don't think the current draft goes into quite enough detail in
answering these questions.  I think the questions I posed below still
apply, even in a requirements document.  Providing guidance to protocol
designers is still appropriate.

-derek

[email-masked] writes:

> Hi Derek,
>
> As the author of the document, I am trying to describe in this requirements ID
> the flexibility of setting up the security policies (as Adrian notes) rather
> then the application specifics of picking a security policy for a given
> application.  Earlier versions of this ID included this information, but was
> dropped since it was out of scope for the routing protocol.  
>
> I have recently been requested to draft an ID for the 6LowAPP that would deal
> specifically with Building Applications at the application layer rather than
> at the routing layer.  Here, I intend to reinject into this new ID specificity
> as to when different security strategies are required.  I have attached a
> spreadsheet that describes 5 different security policies (rows) that must be
> configurable for many different types of commercial buildings with the varying
> requirements for each building type (columns).  I intend to redraft this
> spreadsheet into a section of the ID.  
>
> I hope this is more of what you're looking for and can accept that I will put
> is into a separate ID.  If you think any of this should be put into the
> existing requirements ID, let me know and I will add it in.
>
> Best Regards,
>
> Jerry Martocci
>
> Adrian Farrel                       To Derek Atkins <[email-masked]>,         
> <[email-masked]>             [email-masked], [email-masked]          
>                                     cc [email-masked],            
> 09/20/2009 05:00 AM                    [email-masked], 
> ┌────────────────────────────┐         [email-masked],              
> │     Please respond to      │         [email-masked],                      
> │       Adrian Farrel        │         [email-masked]              
> │ <[email-masked]> │ Subject Re: sec-dir review of                   
> └────────────────────────────┘         draft-ietf-roll-building-routing-reqs-07
>
> Hi Derek,
>