Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07 Mon, 21 September 2009 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 401AF28C186; Mon, 21 Sep 2009 09:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.34
X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lvLc6AQF5Ayx; Mon, 21 Sep 2009 09:02:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D313D3A6A7A; Mon, 21 Sep 2009 09:01:53 -0700 (PDT)
Received: from source ([]) (using SSLv3) by ([]) with SMTP ID; Mon, 21 Sep 2009 09:03:19 PDT
Received: from ([]) by (Lotus Domino Release 8.0.1) with ESMTP id 2009092111060413-5075836 ; Mon, 21 Sep 2009 11:06:04 -0500
In-Reply-To: <9C47E4DAD6D4409488F2107ADD4C964A@your029b8cecfe>
MIME-Version: 1.0
To: Derek Atkins <>
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <>
Date: Mon, 21 Sep 2009 10:59:52 -0500
X-MIMETrack: Serialize by Router on at 09/21/2009 11:02:22 AM, Itemize by SMTP Server on 8.0.1|February 07, 2008) at 09/21/2009 11:06:04 AM, Serialize by Router on 8.0.1|February 07, 2008) at 09/21/2009 11:06:59 AM
Content-Type: multipart/mixed; boundary="=_mixed 0057E0C186257638_="
X-Mailman-Approved-At: Mon, 21 Sep 2009 13:23:00 -0700
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: Mon, 21 Sep 2009 16:02:19 -0000

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 

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 <> 
09/20/2009 05:00 AM
Please respond to
Adrian Farrel <>

Derek Atkins <>,,
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 
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 

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 
protocol spec or an applicability statement would describe what must be 

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.


>> 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.