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

[Vint Cerf <[e-mail]>]

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 <[e-mail]> 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)
>
>