Re: [secdir] Secdir review of draft-baker-ietf-core-11.txt

Fred Baker <fred@cisco.com> Mon, 10 January 2011 11:45 UTC

Return-Path: <fred@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B735D3A6953; Mon, 10 Jan 2011 03:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.455
X-Spam-Level:
X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej3YkB-HZYDE; Mon, 10 Jan 2011 03:45:18 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 512DF28C10E; Mon, 10 Jan 2011 03:45:18 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAEeAKk2rR7Hu/2dsb2JhbACCOaIFc6QFl2CFTASEZ4YjgyA
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 10 Jan 2011 11:47:31 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0ABlQUQ022754; Mon, 10 Jan 2011 11:47:31 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 10 Jan 2011 03:47:31 -0800
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 10 Jan 2011 03:47:31 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <D80EDFF2AD83E648BD1164257B9B09122C2F2C86@TK5EX14MBXC115.redmond.corp.microsoft.com>
Date: Mon, 10 Jan 2011 03:47:17 -0800
Message-Id: <4017D939-EA36-435F-BE31-D010399CFEAB@cisco.com>
References: <D80EDFF2AD83E648BD1164257B9B09122C2F2C86@TK5EX14MBXC115.redmond.corp.microsoft.com>
To: Charlie Kaufman <charliek@microsoft.com>
X-Mailer: Apple Mail (2.1082)
Content-Type: multipart/alternative; boundary="Apple-Mail-128-672740972"
Cc: "draft-baker-ietf-core.all@tools.ietf.org" <draft-baker-ietf-core.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-11.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2011 11:45:19 -0000

On Jan 9, 2011, at 11:43 PM, Charlie Kaufman wrote:

> 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.
>  
> I don’t know the back story on this document. It is an individual submission, I assume targeting Informational status. The title is “Internet Protocols for the Smart Grid”. I didn’t immediately know what “Smart Grid” referred to, and the document assumes the reader already knows, but a quick web search says that current usage is for an upgrade to the electrical power grid supporting innovations like having large numbers of small providers and intelligently managing load (i.e. turning off low priority devices under conditions of peak load) so that we don’t need to provision for peak loads so much larger than average loads.

Correct. in the next version of the document, I plan to quote a few words from the wikipedia article on the Smart Grid in the introduction.

> Most of this document has little to do with the Smart Grid. It is largely an overview of the Internet Protocol Suite referencing the relevant RFCs for details. I would have thought that such an overview would already exist, but my quick search of RFCs did not find one. This would be a handy document to be able to point newbies at, though this title might dissuade them. It’s possible that this overview leaves out broad swaths of IETF work  on the theory that it would be irrelevant to Smart Grid designers, but such filtering was not obvious.
>  
> The part of this document that is about the Smart Grid is Appendix A, which speculates on several ways the Smart Grid might take advantages of Internet technology. I would hope that the people designing the Smart Grid would be familiar with the Internet Protocol Suite, but perhaps I’m being naïve.

The document was requested by US NIST, which is taking the lead on national Smart Grid requirements and standards, in the context of the Smart Grid Interoperability Panel, which I am the IETF's designated liaison to. I also chair the Smart Grid Directorate in the IETF.
 
> Security is one of the most important challenges designers of a Smart Grid will face, and this document emphasizes parts of the Internet Protocol Suite that provide security and that might be applicable (i.e. IPsec, TLS, XML-DSIG, and S/MIME). [Note: I believe a reference to CMS would be more useful than the indirect references to it via S/MIME]. It does not address (that I saw) the fact that since the Smart Grid is a real time control system, dealing effectively with Denial of Service attacks will be particularly important in this context. While a lot of work has gone into QoS guarantees on the Internet, my impression is that most of that work is not standardized. The fact that the use of the power grid as a networking mechanism appears to target non-general purpose use (i.e. it does not appear anyone is planning to run on-demand video over it) makes it plausible that this problem is solvable.

Since I am not a security expert, I have been asking Russ for help from the security community; the security person he asked to help out on the directorate told me that "I am not being paid for this, so I don't plan to offer material help" during the IETF meeting in Anaheim last year. I'd be very willing to mention CMS, if the Security Directorate would like me to. I have little idea what CMS is or how it would be used in this context, however, and would appreciate constructive assistance from the Security Directorate on these sections.

> Because this document does not propose a specific protocol, is has only a token “Security Considerations” section (that notes that security is discussed in some other sections). That seems appropriate to me.
>  
> I noted a couple of typos:

Thanks, I'll pick these up in the next revision.

> P50 next to last line: “a distributed application in a set collectors” -> ???
>  
> P52 first line: unbalanced quotes.
>  
>