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

Derek Atkins <> Wed, 23 September 2009 14:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBE7E3A682E; Wed, 23 Sep 2009 07:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v8JMSjsAB1zR; Wed, 23 Sep 2009 07:25:47 -0700 (PDT)
Received: from (MAIL.IHTFP.ORG []) by (Postfix) with ESMTP id 95E743A67E7; Wed, 23 Sep 2009 07:25:47 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by (Postfix) with ESMTP id 8DE3F8B4005; Wed, 23 Sep 2009 10:26:52 -0400 (EDT)
Received: (from warlord@localhost) by (8.14.3/8.14.2/Submit) id n8NEQWjB031346; Wed, 23 Sep 2009 10:26:32 -0400
References: <>
From: Derek Atkins <>
Date: Wed, 23 Sep 2009 10:26:32 -0400
In-Reply-To: <> (Jerald P. Martocci's message of "Mon\, 21 Sep 2009 10\:59\:52 -0500")
Message-ID: <>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Cc:,,,,,, Adrian Farrel <>
Subject: Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Sep 2009 14:25:48 -0000


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 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 <>,         
> <>   ,          
>                                     cc,            
> 09/20/2009 05:00 AM          , 
> ┌────────────────────────────┐,              
> │     Please respond to      │,                      
> │       Adrian Farrel        │              
> │ <> │ Subject Re: sec-dir review of                   
> └────────────────────────────┘         draft-ietf-roll-building-routing-reqs-07
> 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
>>> 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   
       Computer and Internet Security Consultant