Re: [smartpowerdir] SmartGrid Status Update Please

Jari Arkko <jari.arkko@piuha.net> Fri, 06 May 2011 09:26 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: smartpowerdir@ietfa.amsl.com
Delivered-To: smartpowerdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7884E06C8; Fri, 6 May 2011 02:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level:
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W4Lnat1VvIb; Fri, 6 May 2011 02:26:10 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D0F0EE0651; Fri, 6 May 2011 02:26:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 26AA82CC4B; Fri, 6 May 2011 12:26:07 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tw7C8HxxM2F; Fri, 6 May 2011 12:26:06 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2079D2CC2F; Fri, 6 May 2011 12:26:06 +0300 (EEST)
Message-ID: <4DC39CBB.3070907@piuha.net>
Date: Fri, 06 May 2011 09:01:15 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <AB464FFF-134F-4EA3-A59A-23E2FBC14705@vigilsec.com> <53A33168-135E-4114-9EEE-D4E17F847FB2@cisco.com> <4DC232ED.90106@piuha.net> <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com>
In-Reply-To: <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: IESG IESG <iesg@ietf.org>, IETF SmartPower Directorate <smartpowerdir@ietf.org>
Subject: Re: [smartpowerdir] SmartGrid Status Update Please
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpowerdir>
List-Post: <mailto:smartpowerdir@ietf.org>
List-Help: <mailto:smartpowerdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2011 09:26:11 -0000

Thank you. This was very useful.

Jari

Fred Baker kirjoitti:
> On May 4, 2011, at 10:17 PM, Jari Arkko wrote:
>
>   
>> This is helpful, but I would also be interested in the other direction. That is, what is SGIP doing (have they gone for IP? IPv6? What are they focusing on now? What are their primary unfulfilled requirements?)
>>     
>
> The SGIP is in the process of describing the standards that are important in the grid. Part of that means "today" and part means "tomorrow".
>
> They have generally gone for IP, and for IPv6. Sliding IPv6 in wherever IPv4 is in use now means updating a broad array of existing standards, mostly from the IEC. I personally don't plan to do that; help from any interested quarter would be appreciated.
>
> The SGIP, however, also feels that the ANSI C12 series of standards has present commercial importance. There are a number of issues with that, not the least of which is that US NIST has not certified the security profile for use in communication with the US government; any nuclear facility has to talk with Department of Energy, and there are important ties to Department of Commerce and other areas. From my perspective, the biggest worry is that ANSI C12.19 (a MIB by any other name, but one in which three tables have to be read and understood before one can interpret the remainder; for example, the choice of big-endian, little-endian, or BCD representation is a per-meter option) is hopelessly complex and doesn't quite interoperate with IEC TC 57's CIM. I am also disturbed by it being an OSI ACES/ROSE application layer network that uses UDP/IPv[46] or TCP/IPv[46] as one of a number of underlying networking options.
>
> Another huge issue is embedded in Zigbee. Various factions, including important vendors, the UK, and the Texas Public Utility Commission, have adopted and started to deploy Zigbee Secure Energy Profile (SEP) 1, which presumes a link layer network and an application layer gateway at the Energy Services Interface (ESI). SEP 1 is essentially proprietary; different implementations don't necessarily talk with each other, security has been handed to Certicom with attendant commercial issues, and there are other problems. SEP 2 is an IPv6 network using 6lowpan and RPL, with yet-another-CIM that kinda-sorta interoperates with ANSI C12 or IEC TC 57's CIM, but not quite, and which uses draft-mcgrew-tls-aes-ccm-ecc to bypass Certicom. SEP 2 is nominally link layer independent, which means that it could run over a variety of technologies: IEEE 802.15.1 Bluetooth, IEEE 802.15.4, 802.15.4g, IEEE 1901 Homeplug, ITU G.9955/G.9956 Powerline Communications, and hybrid networks that route between 802.3, 802.11, and the others. However, Zigbee remains wedded strongly to IEEE 802.15.4, so rumor has it (and yes, it's just rumor) that the WiFi Alliance and the Homeplug consortium are having internal discussions about possibly adapting and changing SEP 2 independently to use their link layers. I don't know what the implications would be if that happened, but if I were the AD over the relevant IETF work groups I would want to understand the implications for 6lowpan, RPL, and COAP. Speaking strictly for myself, with the exception of Bluetooth (which probably becomes a local interface to an application) I would prefer to see those simply become IPv6 networks, as most of them can handle a 1500+ byte frame. That story - if it's anything more than a rumor, which at this point I don't know - remains to be told. 
>
>
>
>