Re: [smartpowerdir] Summary of Smart Power matters July 2010

[Jari Arkko <[e-mail]>]

Fred,

Thank you for the report.

A few comments inline:

Your chair has asked me to brief you on what's happening in the Smart Grid. I'm going to do so verbally at dinner this evening, but here is a note summarizing matters in case I miss a point or it doesn't make it across.

The electrical grid today is composed of a lot more than generators, transmission and distribution systems, and meters at homes. It also includes market entities, network operations similar to the operational issues of computer networks, and front end "electrical utilities" that primarily manage billing relationships with consumers. Like the Internet, these are often separate companies that work together through a system of established trust, and which depend on machine-to-machine communications to accomplish their daily tasks. Over the past two decades, http://en.wikipedia.org/wiki/SCADA" rel="nofollow">SCADA systems have been developed that facilitate the management of various things, and standards have been developed (primarily through ANSI-acredited bodies and the IEC) for their interoperation. The grid is also being extended. Where in the past the grid has delivered electricity to consumers and any networks in it have been primarily for the purpose of managing that one-way flow, increasingly consumers are also producers of energy and share their production, via the grid, with their neighbors, which can be a good thing but also has dangers and operational problems. Home automation results in fundamental changes to the concept of an electrical switch and other common elements - where the switch used to make or break a contact, it now often sends a message to a computer that controls such things. And the electrical utilities have discovered that by appropriate planning they can achieve measurable (on the order of 30%) economies, especially if consumers will cooperate with them in supplying information and accepting temporary shutdowns or rate changes to manage load.

The problem with the grid is not that it lacks intelligence; it is that it is a cacophony of voices, speaking every possible language, often proprietary ones. I have spoken with utilities that use DECNET IV to run their SCADA systems. There are vendors that use ANSI C12.19 (a "MIB" by any other name) and C12.21/22 (an ACSE/ROSE-based communication protocol intended to facilitate secure communications between managers and managed systems) and either love it or hate it; many use just enough of C12.19 to be able to say they support it and place their attributes in the "proprietary extensions" tree, and I know of at most one or two full implementations. Some parts of the grid use application-on-Ethernet or other "interesting" architectures.

NIST's objective is to reduce the babble to a dull roar, and provide a way forward that facilitates communication.

This indeed very much a necessary action.

In the words of the NIST Roadmap, Version 1.0, September 2009, “…the Network should enable an application in a particular domain to communicate with an application in any other domain in the information network, with proper management control over who and where applications can be interconnected.” In my opinion, that is eminently doable using IPv4 or IPv6, and IPv6 should be chosen due to address space limitations. Many of the security issues ("how do you certifiably prevent script kiddies from attacking critical infrastructure in both the back office and the technical plant?") is readily handled by routing: "don't advertise the prefixes of critical infrastructure to folks that have no need to access it." For issues for which that is not adequate, strong mutual authentication/authorization and encryption is required.

My initial project in this was, in response to a request from NIST, to write a document that describes the Internet Architecture and its core protocols. This internet draft is http://tools.ietf.org/html/draft-baker-ietf-core" rel="nofollow">Internet Protocols for the Smart Grid, by Monday morning in its -06 version, and probably due one or two more iterations. What I originally intended to describe included IPv4, IPv6, ICMP and ICMPv6, a handful of transports, and the use of IPsec and TLS for security purposes; in response to specific requests, it has grown to reference ~150 internet drafts and RFCs, and will likely add a few more surrounding network management. It has had review from the security directorate, which in essence said they didn't like it but have not responded with suggestions for how to improve it beyond "reference CMS" (of the 27 RFCs under that rubric, which, and saying what? Presumably at least 5275 and 5652...); the easy part of a review is to say something is wrong, but what I need is for someone to suggest text that is right.

I think some of this growth was justified, but there has to be a limit. I think we need to push back on how long the list of core communication mechanisms are. Ultimately, all sane IETF RFCs are usable in some context, but you do not want to reference everything. I think your approach to looking at layers in the document is rational and I would resist attempts to add more information. I am sure that more information is needed, but you can also do that in future documents that might look at higher layers or specific problem areas.

It has also had review from one of the Applications Area Directors, who didn't like the proposed model of the architecture; her suggestion for a way to improve it was "recommend RESTful HTTP". Neither has been, in my opinion, very helpful. The Smart Grid community has stated, however, that this document is useful to them and largely serves the purpose for which it was requested - but they hope for other documents that drill a level deeper into specific areas, such as making security recommendations. I hope to conclude the development of this draft in the near future and send it off for consideration as an Informational RFC.

I don't think your document currently talks about layers above transport, correct? If so, I would leave it at that and make another document that recommends core/restful http. Maybe "Recommendations for Application and Middleware Protocol Toolkits for Low-Powered Networking".

My sense, as I embarked on the project a year ago, was that given http://datatracker.ietf.org/wg/6lowpan/charter/" rel="nofollow">6LowPAN and http://datatracker.ietf.org/wg/roll/charter/" rel="nofollow">Roll, the IETF had little to do beyond this; the bits and pieces needed are in place and in use. In general, I continue to be of that opinion: much of the Smart Grid is very similar to any industry's back office. It uses the same equipment and software, and the real time automation used in the grid is well served by the tools at hand.

I think we have the base and with the base we have little to do. That being said, I do believe that on higher layers there will be more work. There will be optimizations, middleware protocol designs, etc that tailor to some subset of the 10,000 smart grid applications.

That said, the designers of IEEE 802.15.4 have not done the industry any favors. As a result there has been concern regarding the use of any protocol that uses half of the 128 byte MAC frame to encode the network protocols and the remainder for a paltry payload, and the reliability of delivery has been a problem as well. This has resulted in part in spinning up the https://datatracker.ietf.org/wg/core/charter/" rel="nofollow">CORE working group, whose primary effort has been http://tools.ietf.org/html/draft-ietf-core-coap" rel="nofollow">CoAP, and demonstration efforts within Zigbee showing the technology operating perfectly well using standard SOAP or RESTful HTTP on TCP.

OK

At this point, the folks working on the "Home Area Network" or HAN (which is to say people from the Zigbee Alliance) have identified several usability issues, which they are bringing back to the IETF through the usual ad hoc channels. They tell me that these revolve around:

a) getting 6LowPAN to publish some drafts that appear to be finished but await working group chair movement. 6lowpan-nd and -hc need to be completed.

This is serious, and we are following up on this. Ralph has heard the complaints from several directions.

b) 6lowpan WG has not produced a comprehensive "IP over 802.15.4" document that addresses all the 802.25.4-specific details about how to use the radios, how to pick a PAN, how to join a network, etc. Ideally, Zigbee should be able to say "use these RFCs", and can't.

Indeed.

c) Getting Roll to deliver a stable and functional protocol. This is political and controversial between the participants in the discussion. RPL provides two modes: one in which a router is expected to store a route table, and one in which it stores at most a few routes. The latter mode, until the recent reposting of the draft, only supported routing from a sensor to a router at the edge, not from the router back to the sensor. In this edition, WGLC to complete 29 July, RPL's low memory mode depends on source routing (which in turn depends on two drafts submitted to 6man that it has not yet accepted) from the edge router, which may have IPR issues - which has led Zigbee to assert that it is only interested in networks small enough to use the "stored route table" model. Zigbee gave Roll a hard deadline for a stable protocol, 29 July; at the moment, the alternative on the table is DYMO, and there are in my mind issues with that as well.

Yes.

I'll add that I have had concerns in the Roll space due highly optimized complex requirements and the desire to mix application layer and routing logic. Asking for IPv6 extensions is also a big request. They may make sense, but my overall advice would be to ship something that works even if it may be suboptimal in some sense.

d) Meanwhile, Geoof Mulligan organized a Bar BOF at the Anaheim meeting and is proposing one in this meeting, toward designing a mesh-under routing protocol. Requirements development for such a protocol is within the 6lowpan charter. I have made some suggestions along the furrows plowed by Paul Tsuchiya's Landmark Routing algorithm; there are also other possible approaches. Given the "we need something now" mentality, I suspect the question is coming up too late.

I'll note that the working group has existed for a number of years and it is still unclear exactly what architecture they are doing. At the same time, while the complex ND optimizations have depended on the architecture questions, the working group has not progressed simple specifications that other bodies were waiting for.

e) For service location purposes, Zigbee proposes to use Multicast DNS, which has been taking too long and which only returns link-local addresses (if I am at the utility and need to talk with the Energy Management System [EMS] in a home, I want to be able to get a global address in response to a DNS translation). One could argue for Dynamic DNS with the DNS server in the Energy Management System (which may be part of or sitting next to the meter), or for a more static solution. I'm not sure where the service location protocol might fit in this; its security issues may make it useless. CoAP offers a "resource discovery" feature that may obviate the need for M-DNS and service discovery.

This is an issue.

f) Regarding CORE/CoAP: it would be good if the Zigbee Alliance could get some numbers to support or disprove the statement "HTTP/TLS/TCP will meet our performance requirements for SEP 2.0 in networks of fewer than 30 nodes".  There's a concern that CoAP will result in a walled garden of SEP 2.0 nodes, where any CoAP/HTTP gateway will stifle application development. There is also good reason to be concerned about making Secure Energy Profile 2.0 dependent on Yet Another RFC from a WG that is just now getting started. Note that CoAP is seen as the backup in case HTTP/TLS/TCP turns out for naught, not a primary requirement. And CoAP is experiencing mission creep...

OK

g) Open standards for cryptography can and should be used.  Current work suggests that standard mechanisms like TLS and PKIX are suitable for use in SG's constrained environments, given some modest profiling that fits into Internet standards rather than changing those standards (http://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm" rel="nofollow">AES-CCM, http://www.ietf.org/id/draft-pritikin-comp-x509" rel="nofollow">Cert Compression).   Cryptographic algorithms can and should use open specifications that predate specialized methods (http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc" rel="nofollow">Fundamental ECC).  

Absolutely.

h) PANA relay

?

i) As you may be aware (I was not), security in the HAN is at the moment being derived from 802.1X using EAP-TLS (RFC 5216) at the link layer. In short, devices that enter the HAN should be those that are authorized access. A comment I got from a NIST security architect (Justin Searles) said that was the best security available today. It gives me some concern, however, as the fact that one is authorized to use a network doesn't mean one is authorized to do anything in particular in the network - the fact that I can attach my laptop doesn't mean I can reconfigure the routers, for example. I'd be interested in other views...

I think you are right.

j) NIST is asking questions about secure network management. I have suggested Netconf, and there is review happening both by the relevant chairs and by a NIST consultant along those lines. Depending on the analysis, Netconf may have some things to address - at this point TBD.

OK

Jari