Return-Path: 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 80BD928C0CF; Sun, 9 Jan 2011 23:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 gmkNIYOwe9FC; Sun, 9 Jan 2011 23:41:29 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id F218428C0E5; Sun, 9 Jan 2011 23:41:28 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 9 Jan 2011 23:43:35 -0800 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.135]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Sun, 9 Jan 2011 23:43:35 -0800 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-baker-ietf-core.all@tools.ietf.org" Thread-Topic: Secdir review of draft-baker-ietf-core-11.txt Thread-Index: AcuwlFYRhTqo2OiETVufesZBsiT2pw== Date: Mon, 10 Jan 2011 07:43:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B09122C2F2C86TK5EX14MBXC115r_" MIME-Version: 1.0 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 07:41:35 -0000 --_000_D80EDFF2AD83E648BD1164257B9B09122C2F2C86TK5EX14MBXC115r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. I don't know the back story on this document. It is an individual submissio= n, I assume targeting Informational status. The title is "Internet Protocol= s 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 sea= rch says that current usage is for an upgrade to the electrical power grid = supporting innovations like having large numbers of small providers and int= elligently managing load (i.e. turning off low priority devices under condi= tions of peak load) so that we don't need to provision for peak loads so mu= ch larger than average loads. Most of this document has little to do with the Smart Grid. It is largely a= n overview of the Internet Protocol Suite referencing the relevant RFCs for= details. I would have thought that such an overview would already exist, b= ut 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 filter= ing 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 Interne= t technology. I would hope that the people designing the Smart Grid would b= e familiar with the Internet Protocol Suite, but perhaps I'm being na=EFve. Security is one of the most important challenges designers of a Smart Grid = will face, and this document emphasizes parts of the Internet Protocol Suit= e 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, de= aling effectively with Denial of Service attacks will be particularly impor= tant in this context. While a lot of work has gone into QoS guarantees on t= he Internet, my impression is that most of that work is not standardized. T= he 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 so= lvable. Because this document does not propose a specific protocol, is has only a t= oken "Security Considerations" section (that notes that security is discuss= ed in some other sections). That seems appropriate to me. I noted a couple of typos: P50 next to last line: "a distributed application in a set collectors" -> ?= ?? P52 first line: unbalanced quotes. --_000_D80EDFF2AD83E648BD1164257B9B09122C2F2C86TK5EX14MBXC115r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  These comments were written primarily for the benefi= t 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. Th= e title is “Internet Protocols for the Smart Grid”. I didn̵= 7;t immediately know what “Smart Grid” referred to, and the document assumes the reader already knows, but a quick web search says tha= t current usage is for an upgrade to the electrical power grid supporting i= nnovations like having large numbers of small providers and intelligently m= anaging load (i.e. turning off low priority devices under conditions of peak load) so that we don’t nee= d to provision for peak loads so much larger than average loads.=

 

Most of this document has little to do with the Smar= t Grid. It is largely an overview of the Internet Protocol Suite referencin= g 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 pos= sible 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 Gr= id is Appendix A, which speculates on several ways the Smart Grid might tak= e 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=EFve.

 

Security is one of the most important challenges des= igners 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 th= at 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 in= to 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 networkin= g mechanism appears to target non-general purpose use (i.e. it does not appear anyone is planning to run on-demand v= ideo over it) makes it plausible that this problem is solvable.<= /p>

 

Because this document does not propose a specific pr= otocol, is has only a token “Security Considerations” section (= that notes that security is discussed in some other sections). That seems a= ppropriate to me.

 

I noted a couple of typos:

 

P50 next to last line: “a distributed applicat= ion in a set collectors” -> ???

 

P52 first line: unbalanced quotes.

 

 

--_000_D80EDFF2AD83E648BD1164257B9B09122C2F2C86TK5EX14MBXC115r_--