Re: [smartpowerdir] A view on Zigbee Security Energy Profile 1.x

Vint Cerf <vint@google.com> Thu, 07 April 2011 09:55 UTC

Return-Path: <vint@google.com>
X-Original-To: smartpowerdir@core3.amsl.com
Delivered-To: smartpowerdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116A128C0F8 for <smartpowerdir@core3.amsl.com>; Thu, 7 Apr 2011 02:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 SFydSoPonUwa for <smartpowerdir@core3.amsl.com>; Thu, 7 Apr 2011 02:55:13 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 68B7B3A69C0 for <smartpowerdir@ietf.org>; Thu, 7 Apr 2011 02:55:13 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p379uvv5015223 for <smartpowerdir@ietf.org>; Thu, 7 Apr 2011 02:56:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302170217; bh=k9TdA6lX8zqowj756JzwdCKy5PQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ydLaLx53WNFjyWQnCS11DrtRVtLX3HusLPLltcj1JRZ8hheXf18qw4ZpFYbq7eood hAiNPa3l+yy1UvMsPBm2g==
Received: from qwc23 (qwc23.prod.google.com [10.241.193.151]) by hpaq5.eem.corp.google.com with ESMTP id p379uJ72021688 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <smartpowerdir@ietf.org>; Thu, 7 Apr 2011 02:56:56 -0700
Received: by qwc23 with SMTP id 23so1319672qwc.3 for <smartpowerdir@ietf.org>; Thu, 07 Apr 2011 02:56:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y9B+0eb4POzDCMptWDhE1+Shj5eK80LVFzm9Kt/8bU8=; b=EgaE1Vw8jY1M+f/hDIu1woIq2IS3kbOF9ejiJbDpZaTtTr2vU49iViUfrXvkTNBpQE PhXVqjHSUZqbfIfKTI2g==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hq609MhMVlC1zuXd2KMKYSIkoGeC5ffbjm9pEDiLLPmPVI0PbbkoHTuXuJ8LLs9HEK LXnsfUEiOci8uzjojf2g==
MIME-Version: 1.0
Received: by 10.229.101.36 with SMTP id a36mr447874qco.74.1302170215519; Thu, 07 Apr 2011 02:56:55 -0700 (PDT)
Received: by 10.229.253.7 with HTTP; Thu, 7 Apr 2011 02:56:55 -0700 (PDT)
In-Reply-To: <D808FCD7-BA58-491B-9954-B59557919492@gmail.com>
References: <D808FCD7-BA58-491B-9954-B59557919492@gmail.com>
Date: Thu, 7 Apr 2011 05:56:55 -0400
Message-ID: <BANLkTimk4o+dyfzEKTZ1t2eZ7+Z2B_Y2Sw@mail.gmail.com>
From: Vint Cerf <vint@google.com>
To: Fred Baker <fredbakersba@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: chair@ietf.org, SGIPGB-MEMBERS@smartgridlistserv.org, chair@iab.org, IETF SmartPower Directorate <smartpowerdir@ietf.org>
Subject: Re: [smartpowerdir] A view on Zigbee Security Energy Profile 1.x
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 07 Apr 2011 09:55:15 -0000

Fred,

I think this is a fair statement. However, if this is intended as an
argument against public documentation of SEP 1.x, I would like to
observe that the IETF or at least the Internet Architecture Board, has
sanctioned publication of other than IETF standards simply for
purposes of having that documentation readily available for vendors,
users and operators faced with interacting with equipment that is not
standard. IETF is careful to mark such documents as NOT IETF approved
standards. SEP 1.x might fall into that category. If I were a vendor
faced with making things interwork with other products in the Smart
Grid area, I would want, not only to be compatible with the SGIP
sanctioned standards but would be interested in the possibility of
making equipment that could gateway to the non-standard equipment as a
bridge towards normalization.

I support your conclusions that SEP 1.x does not appear to meet the
conventional requirements of IETF-sanctioned standards and ought not
to be treated as SGIP-sanctioned either. But, properly "fenced off",
might be documented, for reference purposes only, in, e.g., the
catalog of "standards". Does this make any sense to you?

vint



On Tue, Mar 29, 2011 at 8:43 AM, Fred Baker <fredbakersba@gmail.com> wrote:
> I want to be very careful in identifying myself in sending this; I have not vetted this statement with anyone, so I can't say "this is the IETF's viewpoint". That said, I speak from an IETF perspective, and would be very surprised if anyone in the IETF significantly disagreed. I am the chairman of the IETF's Smart Power Directorate, and the IETF's liaison to the SGIP. http://en.wikipedia.org/wiki/Fred_Baker_(IETF_chair)
>
> The IETF has spent the past 25 years building protocols that numerous operators have used to build a global network that interoperates very effectively. The result has been a significant benefit to business and to national GDP, and has spawned numerous businesses that can add interesting capabilities to a world-wide market. The principles on which the Internet Architecture and its protocols are based include openness of specification, interoperable implementation among multiple vendors, support of competitive business, and an absence of market capture.
>
> To give an idea of how we implement that, let me mention the development of OSPF, a routing protocol commonly used in the Internet. We had leadership from a small group of developers, but a relatively large community that interacted with them to ensure that it met their needs. It considered the needs of government networks, service provider networks, and networks on the Internet edge. The documentation that was presented before it was approved included a publicly readable protocol specification (RFC 1247, which has since been updated), an analysis of its capabilities (RFC 1245), a publicly documented interoperability test that included 23 independent implementations of the complete protocol (RFC 1246), and the capabilities required to manage the protocol (RFC 1253). It is an example of what we consider a well documented open specification.
>
> In addition, while we specified mutual cryptographic authentication between neighboring routers, we didn't specify the company from which certificates had to be obtained, or the type of cryptography involved. There were two reasons: we wanted to avoid market capture by a single organization, with the abuses attendant in such a thing, and we wanted to provide for technological change, which is one of the few constants in the Internet. Security is specified in terms of what is done, not in terms of whose technology is used. Should an issue arise, such as has happened in Stuxnet, it is possible to update operationally without changing the specifics of the protocol.
>
> In reviewing any protocol or protocol suite, the IETF would similarly look at how it is specified, its scalability (for which reason we strongly recommend the use of IP generally, and more specifically IPv6), the publicly available documentation of its testing, security issues, and the business impacts. The IETF would generally recommend that the protocol suite used in the Smart Grid similarly promote an openly specified, widely and interoperable implemented, secure, and scalable network that is designed for business and technological growth and adaptation in time.
>
> From what is publicly known about SEP 1.x, I don't believe that it meets these concerns.
>
> Fred Baker
>
> http://www.ietf.org/rfc/rfc1245.txt
> 1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT=26160,
>     PS=33546, PDF=31723 bytes) (Also RFC1247, RFC1246) (Status:
>     INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc1246.txt
> 1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format:
>     TXT=70441, PS=141924, PDF=84633 bytes) (Also RFC1247, RFC1245)
>     (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc1247.txt
> 1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT=433332,
>     PS=989724, PDF=490300 bytes) (Obsoletes RFC1131) (Obsoleted by
>     RFC1583) (Updated by RFC1349) (Also RFC1246, RFC1245) (Status: DRAFT
>     STANDARD)
>
> http://www.ietf.org/rfc/rfc1253.txt
> 1253 OSPF Version 2 Management Information Base. F. Baker, R. Coltun.
>     August 1991. (Format: TXT=74453 bytes) (Obsoletes RFC1252) (Obsoleted
>     by RFC1850) (Also RFC1247, RFC1245, RFC1246) (Status: PROPOSED
>     STANDARD)
>
>