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

[Fred Baker <[e-mail]>]

FYI - I had run my note yesterday past the 6lowpan chairs before sending it, but they had not seen it to reply. I got this from Geoff this morning; it is only fair to let him correct the record in these respects. Note that JP had in fact replied, and I had adjusted the comments on ROLL with respect to his comments.

Begin forwarded message:

> From: Geoff Mulligan <[e-mail]>
> Date: July 26, 2010 12:34:53 AM GMT+02:00
> To: Fred Baker <[e-mail]>
> Subject: Re: Fwd: Summary of Smart Power matters July 2010
> 
> Fred,
>  I think that this is basically ok.  I do take a few exceptions:
> 
> 1. Zigbee didn't demonstrate RESTful http over 6lowpan and 15.4 - I did
> it.  Now zigbee is planning on using it.
> 
> 2. paragraph a) - The HC and ND drafts are not being delayed by the
> 6lowpan chairs.  There have been fruitful and continuing discussions on
> both drafts.  I think that HC is now done and we will say so in the
> meeting on Monday.  The ND draft needs one for revision and will call it
> complete.  So again these are not waiting on the chairs.
> 
> 3. paragraph b) - JP and David Culler had started and promised a 6lowpan
> "arch" doc.  I volunteered to help, but nothing has come of it.  I do
> agree that it would be good and nice if there were some document the
> described IP over 15.4, but including how to pick a pan and channel and
> join a network is quite a bit of work.  I think that we are chartered to
> do this, but so far no one has stepped up (in 6lowpan) so zigbee is
> defining how to do it for zigbee.
> 
> 4. paragraph d) - I did not hold the bar bof to do anything in the time
> frame for zigbee or the smart grid, but to work on something that
> 6lowpan was supposed to do from the start - RFC4919 describes a network
> that is mesh under.
> 
> 5. paragrpah f) - The other demo I built - showing tcp/http running over
> a multi-hop network included 30+ nodes.
> 
> So basically right, but something thing just slightly askew.  If you
> talk to folks about this after the IAB meeting I hope that you can
> properly reflect these 5 points.
> 
> 	geoff
> 
> 
> On Sun, 2010-07-25 at 06:00 +0200, Fred Baker wrote:
>> What I actually sent.
>> 
>> Begin forwarded message:
>> 
>>> From: Fred Baker <[e-mail]>
>>> 
>>> Date: July 25, 2010 5:54:07 AM GMT+02:00
>>> 
>>> To: IAB <[e-mail]>
>>> 
>>> Cc: IETF SmartPower Directorate <[e-mail]>
>>> 
>>> Subject: Summary of Smart Power matters July 2010
>>> 
>>> Reply-To: IETF SmartPower Directorate <[e-mail]>
>>> 
>>> 
>>> 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, 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. 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 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.
>>> 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. 
>>> 
>>> 
>>> My sense, as I embarked on the project a year ago, was that
>>> given 6LowPAN and 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.
>>> 
>>> 
>>> 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 CORE working group, whose
>>> primary effort has been CoAP, and demonstration efforts within
>>> Zigbee showing the technology operating perfectly well using
>>> standard SOAP or RESTful HTTP on TCP.
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> 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...
>>> 
>>> 
>>> 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 (AES-CCM, Cert Compression).   Cryptographic
>>> algorithms can and should use open specifications that predate
>>> specialized methods (Fundamental ECC).   
>>> 
>>> 
>>> 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...
>>> 
>>> 
>>> 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.
>> 
>> http://www.ipinc.net/IPv4.GIF
>> 
> 
> 

http://www.ipinc.net/IPv4.GIF